[openbeosnetteam] Re: Dragonfly or FreeBSD nestack? was Re: Mailing lists and network team questions
- From: Waldemar Kornewald <wkornew@xxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Sun, 19 Mar 2006 00:22:04 +0100
Axel Dörfler wrote:
You only need about two synchronization semaphores, similar to a
condvar implementation.
The serializing tokens can be anything, for example a flag in a uint32
value.
When acquiring the token, you lock one semaphore - that one just
protects the available tokens. If the token you want is free, you
reserve it, and unlock the semaphore again.
If it's not available, you free all your current tokens, unlock the
first semaphore and wait for the second to become available. When a
token is freed, that semaphore is signalled, and your thread can try to
reacquire its tokens - of course, you can have one of these wait
semaphores per thread, so that the code in "release_token" can exactly
determine which thread to unlock now.
This does not protect you from other threads "stealing" the token you
are waiting for (between releasing sem1 and acquiring sem2), so a real
scheduler would perform better. Also, this would have to be extended
such that you have a list of tokens every thread is waiting for, so the
semaphore is only released when all tokens are available at the same
time. Otherwise you could end up in long-running ping-pong situations
where two or more threads try to get each other's tokens. Now I realize
that the whole token idea is even worse for latency than I thought. With
*many* threads running at the same time you may end up waiting
practically indefinitely if you hold multiple tokens! I'd prefer
semaphores and better cope with dead-locks than have something that
scales so badly. Axel, why did you not mention this earlier? :))
Bye,
Waldemar
Other related posts: