August 2004 - Darwin-kernel

Re: Synchronizing tsleep() and wakeup()
by Jim Magee 03 Aug '04

03 Aug '04

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(a)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.

1 0

Re: Synchronizing tsleep() and wakeup()
by Nikita Danilov 02 Aug '04

02 Aug '04

Eric Long writes: > Hi, > > I've been trying to use tsleep() and wakeup() in a kernel extension, but it > isn't obvious to me how to enforce synchronization of these calls. (Likely, > this isn't the right mechanism for what I want. But, since I'm not sure > what I need to use, I'm bringing it up here.) > > My goal is to put a thread Y to sleep until a condition is met or a time out > occurs. Thread Z is manipulating the condition, then calling wakeup on > Thread Y when it changes. But if thread Z's timing is just right (or should > I say wrong) thread Y may call tsleep after thread Z has decided whether or > not to wake it up. 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). 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. 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. 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. Nikita. > > Searching for a condition lock, I came to this page: > > <http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgrammin > g/synchronization/chapter_15_section_3.html#//apple_ref/doc/uid/TP30000905-C > H218-TPXREF109> > > Which says: > > > The BSD portion of Mac OS X provides tsleep, wakeup, and wakeup_one, which are > > equivalent to condition variables with the addition of an optional time-out. > > Since they are more commonly used for waiting a predetermined period of time, > > these calls are discussed in more detail in the section 3Using tsleep2 as part > > of the 3Miscellaneous Kernel Services2 chapter. > > In my case, I'm not waiting for a predetermined amount of time. In fact, I > may not need to wait at all, if the other thread has changed the value, and > ultimately I only want to sleep until the value has changed or we time-out > and give up waiting for the change. > > What's the best way to do this in the kernel? > > > Thanks, > > > Eri _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

Re: Synchronizing tsleep() and wakeup()
by Brian Bergstrand 02 Aug '04

02 Aug '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 2, 2004, at 12:54 PM, Eric Long wrote: > Hi, > > Which says: > >> The BSD portion of Mac OS X provides tsleep, wakeup, and wakeup_one, >> which are >> equivalent to condition variables with the addition of an optional >> time-out. >> Since they are more commonly used for waiting a predetermined period >> of time, >> these calls are discussed in more detail in the section 3Using >> tsleep2 as part >> of the 3Miscellaneous Kernel Services2 chapter. > > In my case, I'm not waiting for a predetermined amount of time. In > fact, I > may not need to wait at all, if the other thread has changed the > value, and > ultimately I only want to sleep until the value has changed or we > time-out > and give up waiting for the change. > > What's the best way to do this in the kernel? > Sounds like you want Mach semaphores. Check out <mach/semaphore.h> in the Kernel framework. Specifically: semaphore_wait() semaphore_timedwait() semaphore_signal() HTH. Brian Bergstrand <http://www.bergstrand.org/brian/>, AIM: triryche206 PGP Key: <http://www.bergstrand.org/brian/misc/public_key.txt> Let the chips fall where they may, but when the alcohol wears off tomorrow there's going to be one hell of a mess to clean up. - David Muench As of 01:49:22 PM, iTunes is playing "For The Love Of God" from "Passion And Warfare" by "Steve Vai" -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQQ5/m3nR2Fu2x7aiEQI+CwCgzT95NmNzIRLGY7/1f5KZ0jH1e3sAoK4o y7D/P1JgDaSGZ7teaLGQuTUo =SmHG -----END PGP SIGNATURE----- _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

Synchronizing tsleep() and wakeup()
by Eric Long 02 Aug '04

02 Aug '04

Hi, I've been trying to use tsleep() and wakeup() in a kernel extension, but it isn't obvious to me how to enforce synchronization of these calls. (Likely, this isn't the right mechanism for what I want. But, since I'm not sure what I need to use, I'm bringing it up here.) My goal is to put a thread Y to sleep until a condition is met or a time out occurs. Thread Z is manipulating the condition, then calling wakeup on Thread Y when it changes. But if thread Z's timing is just right (or should I say wrong) thread Y may call tsleep after thread Z has decided whether or not to wake it up. Searching for a condition lock, I came to this page: <http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgrammin g/synchronization/chapter_15_section_3.html#//apple_ref/doc/uid/TP30000905-C H218-TPXREF109> Which says: > The BSD portion of Mac OS X provides tsleep, wakeup, and wakeup_one, which are > equivalent to condition variables with the addition of an optional time-out. > Since they are more commonly used for waiting a predetermined period of time, > these calls are discussed in more detail in the section 3Using tsleep2 as part > of the 3Miscellaneous Kernel Services2 chapter. In my case, I'm not waiting for a predetermined amount of time. In fact, I may not need to wait at all, if the other thread has changed the value, and ultimately I only want to sleep until the value has changed or we time-out and give up waiting for the change. What's the best way to do this in the kernel? Thanks, Eric _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

Re: Case-insensitiveness
by Jonas Maebe 02 Aug '04

02 Aug '04

On 2 aug 2004, at 07:49, Kumar Shailove wrote: Darwin is based on FreeBSD, which is case-sensitive in file naming, where as OS X file naming is case-insensitive. This has nothing to do with either OS, but simply with the filesystem that you use. Both FreeBSD and Mac OS X support filesystems that are case-sensitive and filesystems that are case-insensitive. They simply have a different default based the expectations of the largest part of their userbase. Jonas _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

Re: Case-insensitiveness
by Wade Tregaskis 02 Aug '04

02 Aug '04

Darwin is based on FreeBSD, which is case-sensitive in file naming, where as OS X file naming is case-insensitive. Could anybody tell me any specific reason behind this. MacOS has always been case-insensitive. Wade Tregaskis (aim: wadetregaskis) -- Sed quis custodiet ipsos custodes? _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

Case-insensitiveness
by Kumar Shailove 02 Aug '04

02 Aug '04

Hi List, Darwin is based on FreeBSD, which is case-sensitive in file naming, where as OS X file naming is case-insensitive. Could anybody tell me any specific reason behind this. Regards, Shailove. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0