On Aug 2, 2004, at 3:21 PM, Nikita Danilov wrote:

Traditional UNIX tsleep/wakeup mechanism requires some external

synchronization that guarantees that thing you are describing is

impossible. For example, code in BSD portion of XNU that uses

tsleep/wakeup is usually executed under (or should I say `within'?) a

funnel, so that checking condition and entering tsleep occurs

atomically

with respect to the wakeup calls (funnel is automatically released by

low-level scheduler code when thread actually blocks).

Yep.

If you don't want to use funnels, you can resort to MACH

synchronization

primitives, but I, personally, wouldn't recommend this, because they

seem to be designed for programming model different than one normally

employed by UNIX kernel code. For example, MACH semaphore remembers

thread that created it, and can only be destroyed by this thread. This

makes it impossible to embed such a semaphore into dynamically

allocated memory object (like inode). Moreover, all semaphores created

by a thread are automatically destroyed when thread exits. This seems

to

target applications like MACH servers.

Not quite. Mach semaphores are associated with tasks, not threads, and can be destroyed by any thread which has a handle to the task in question.

The simplest route is to create your own condition variable

implementation directly on top of MACH wait_queue_* API and usimple

locks (do _not_ use simple lock: this API is preprocessed to

nothing). If you don't need bells-and-whistles like time-outs,

condition

variables (cond_init, cond_wait, cond_signal, and cond_broadcast) would

require only few dozen lines of C code.

The simplest route is to use the mechanism provided by the subsystem your KEXT lives in. What kind of kext are you writing?

This, by the way, reminds me of some problem: osfmk/kern/kern_types.h

doesn't export real struct wait_queue. Instead is defines a placeholder

of the same size. This means, that initializer also cannot be

provided. That is, one cannot write something like

static struct wait_queue wq = WAIT_QUEUE_INIT(&wq);

This is cumbersome, and it would be really nice if Apple people added

initializer macros for internal kernel data-structures.

This was on purpose. Initialization may not be possible with a macro in some situations - and we don't want to have to get a recompiled kext when it isn't. That's why there is a wait_queue_init() function instead. But that is marked as OBSOLETE. You should be using wait_queue_alloc() if you are going to use any of these interfaces at all - but doing so will require you to link against a specific version of the kernel and/or have to recompile more often that you may like. That's because the raw wait queue mechanisms are NOT part of the Kernel Programming Interfaces (KPIs) recently announced for Darwin 8 and beyond. Sure, the wait_queue_alloc() interface is not going away anytime soon. But to access it you will have to link against the legacy kernel symbol set (Darwin 6 symbols) and nothing else. Either that or against each specific kernel version if you need any of the new kernel interfaces beyond those in Darwin 6 (and will not be able to load against subsequent kernel versions without a recompile/relink of your kext). --Jim [demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.