[openbeosnetteam] Re: Dragonfly or FreeBSD nestack? was Re: Mailing lists and network team questions
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Sat, 18 Mar 2006 22:05:14 +0100 CET
Waldemar Kornewald <wkornew@xxxxxxx> wrote:
> Axel Dörfler wrote:
> > CPU affinity just means that the scheduler *tries* to keep a thread
> > to
> > a certain CPU - if the other CPU has free slots it won't hesitate
> > to
> > take a thread away from the other CPU, though - ie. you can't use
> > this
> > for anything, it's just faster, because the CPU's cache is likely
> > to be
> > trashed less often :)
> On some website I even read that it can mean that a thread is
> restricted
> to a subset of the available CPUs (CPUs 1, 4, and 9, for
> example)...very
> strange.
Well, not everything you read somewhere must be be 100% correct, even
in this list ;)
> > As I said, several times already now: you can easily implement
> > serializing tokens using mutexes. No performance hit at all, and
> > yet,
> > you can't run into the deadlock problem.
> I don't really know how to implement them with mutexes. I.e.:
> whenever I
> block on a mutex all other mutexes held by the current thread would
> have
> to allow for other threads to get the mutexes or am I on the totally
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.
> wrong track, here? To me, mutexes look like special semaphores that
> can
> protect against priority inversion. Could you please clarify? I'm
> just
> curious.
A mutex is just a special form of a semaphore, or better, a specific
usage case for semaphores. They don't protect you against priority
inversion, but they are meant to protect short critical zones.
Bye,
Axel.
Other related posts:
