Subj : Re: Socket programmation with threads
To   : comp.programming.threads
From : Joe Seigh
Date : Tue May 24 2005 12:32 pm

On 24 May 2005 06:51:02 -0700, Jomu <dragisha@gmail.com> wrote:

> Oh, I am very sure there are disadvantages to any implementation of
> anything. But, this works (tm) and I am sure satisfied with performance
> in situations I tried.
>
> But (always some:), I am thrilled here... Ok, signaling is preemptive
> (I've read earlier thread on this and it's very informative) and we
> should avoid it (until they fix it) if possible. Is it possible to fix
> it, say, with only marking some process ready (as oppossed to
> "waiting") and continue, in place where they context switch at signal
> without pause?
>
> Also, as I very much like to use message queues for my interthread
> stuff... Would semaphore based consumer-producer be free of this
> braindeadness we are talking about here?
>
That's specifically where you'll notice it the most.  If you use

    if (sem_trywait(&sem) != 0) {
	sem_wait(&sem);
	sched_yield();
    }

instead of just plain sem_wait, it will run up to 30% faster on Linux
NPTL.  Even faster if you put the generic fast pathed semaphore
algorithm on top of that.

-- 
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

.