Subj : Re: JOB: Sandbridge Technologies, White Plains, NY To : comp.programming.threads From : David Schwartz Date : Fri Jul 15 2005 02:52 pm "Marcin 'Qrczak' Kowalczyk" wrote in message news:87k6jrzte3.fsf@qrnik.zagroda... > "David Schwartz" writes: >> Fundamental rule: If there's any way you can allow a thread to keep >> running until it uses up its timeslice, do that. Only preempt a thread if >> that thread cannot make forward progress or you have a ready-to-run >> thread >> at a higher static priority or *much* higher dynamic priority. > Is there a way to implement mutexes and condvars on Linux/NPTL such > that the signalling thread is not preempted? It doesn't have to be > portable, the only requirement is that it's possible to check whether > it works. I don't think so. The problem is in the kernel which will preempt a process at the drop of a hat to "preserve interactivity", even if it's quite clear that the process it is preempting for is not interactive. > In the runtime of my language I often signal before pthread_cond_wait > and thus I can't move signalling after unlocking, and the preemption > is totally pointless - three context switches instead of one. I know. The Linux kernel folks just don't get threading, and there's no ability to educate them. They see things the way they should be and not the way they are. DS .