March 2003 - Darwin-kernel - lists.apple.com

Re: Wait Queues
by Jim Magee 06 Mar '03

06 Mar '03

On Wednesday, March 5, 2003, at 09:24 PM, Vivek Balasubramanyam wrote: This makes sense, but I just have one more question. If I'm not allocating a wait_queue, then I suppose I need an event_t to wait on and signal. But, event_t is just a void*, so I'm not sure what it actually should be. How about "(void *)&device->readQueue"? As long as that is what gets passed to the thread_wakeup() call, you will be fine. --Jim _______________________________________________ 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: Wait Queues
by Vivek Balasubramanyam 06 Mar '03

06 Mar '03

This makes sense, but I just have one more question. If I'm not allocating a wait_queue, then I suppose I need an event_t to wait on and signal. But, event_t is just a void*, so I'm not sure what it actually should be. On Wednesday, March 5, 2003, at 01:00 PM, Jim Magee wrote: On Wednesday, March 5, 2003, at 03:38 PM, Vivek Balasubramanyam wrote: I am definitely not giving up the CPU, although I expected that the assert_wait() function would put my thread to sleep. Are you saying that I need to call thread_block() in addition to assert_wait() in order to fall asleep? Correct. In Mach, blocking within the kernel is a two step process. You assert your intention to wait on a particular event, and then you block. Normally, you would unlock whatever you were using for synchronization after calling assert_wait() and before giving up the CPU (with thread_block()). This two stage approach has several advantages: 1. It allows you to use whatever form of synchronization you want (because you do the unlocking manually between the assert_wait() and the thread_block(). 2. It also allows you to check the return from assert_wait() to see if you really should block. For instance, you may be aborted because of a pending signal or thread termination, and the wait may have been interruptible, in which case the assert_wait() didn't have effect. So, no need to give up the CPU, just return the interrupted status so you can get to your signal handler quickly. 3. Once you unlock, but before you try to give up the CPU, the event may get posted (by another thread on another CPU, by a thread that preempts you on this CPU, or by an interrupt handler). By giving a window for this to happen before you commit to giving up the CPU, you may avoid unnecessary context switches. There isn't a specific need to use wait queues over any other kind of synchronization, since only one thread is ever in the queue. But I do need to use something that will let this thread sleep until a separate thread sends a wakeup signal (when the buffer goes from empty to non-empty). Note that you don't have to allocate your own wait_queues. There are a standard set of them for the system. If you just call assert_wait(), your event will be hashed to select one of the standard wait_queues to put you in. You only need your own wait_queue if you are going to use the wait_queue's native locking as your wider synchronization primitive (not available outside the osfmk component, but used by both Mach message queues, semaphores, and locksets) or if you need to manage sets of related waiters and event sources (like Mach portsets or BSD select sets, etc...). --Jim _______________________________________________ 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: Wait Queues
by Quinn 05 Mar '03

05 Mar '03

At 12:38 -0800 5/3/03, Vivek Balasubramanyam wrote: There isn't a specific need to use wait queues over any other kind of synchronization, since only one thread is ever in the queue. But I do need to use something that will let this thread sleep until a separate thread sends a wakeup signal (when the buffer goes from empty to non-empty). I get the feeling you're barking up the wrong tree here. Specifically, if you have an I/O Kit driver that installs a character device, Mach primitives are probably too low-level. Instead, you should probably be using BSD primitives, such as "sleep" and "wakeup". Of course, to use these from within a I/O Kit driver, you have to manually acquire the appropriate BSD funnel. You can see all of this in the IOSerialBSDClient driver, which is Apple's code to shim from I/O Kit into a BSD character device. <http://www.opensource.apple.com/cgi-bin/registered/cvs/IOSerialFamily/IOSer…> [APSL account required] Another option might be to publish *two* nubs from your driver, the first one being the actual modem and the second being the monitoring device. I/O Kit will then match IOSerialBSDClient on top of each, and you can let it shim you into BSD. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Technical Support * Networking, Communications, Hardware _______________________________________________ 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: Wait Queues
by Jim Magee 05 Mar '03

05 Mar '03

On Wednesday, March 5, 2003, at 03:38 PM, Vivek Balasubramanyam wrote: while (1) { /* synchronize with other reads */ while(lkvi_use_lock_use_when_unused(&(device->rLock)) != 0) {}; bytesAvailable = device->bufWrIdx - device->bufRdIdx; if (bytesAvailable < 0) bytesAvailable += device->bufSize; if ((device->buf != NULL) && ((bytesAvailable > 0) || (device->flags & SMD_OUTPUT_DEVICE_FLAG_TRAILING_EOF))) break; /* keep the lock since we'll need it anyway */ lkvi_use_lock_unuse(&(device->rLock)); /* SMD_PRINT_DEBUG_INFO (("Going to sleep")); */ lkvi_wait_queue_sleep_interruptible (&device->readQueue); /* SMD_PRINT_DEBUG_INFO (("Woken up")); */ } Now that I look at your code, it is prime justification for the 2 stage mach assert_wait(), thread_block() mechanism. You "unuse" your lock before sleeping. This opens you up to a race condition on preemptible/smp kernels like ours. What happens if the wakeup occurs after the lock but before you get a chance to sleep? You'll miss it and potentially sleep forever. Using the Mach style, it would be more like: while(lkvi_use_lock_use_when_unused(&(device->rLock)) != 0) {}; while(1) { ... if (bytesAvailable > 0 || ...) break; wait_result = lkvi_wait_queue_assert_wait_interruptible(&device->readQueue); if (wait_result == THREAD_WAITING) { lkvi_use_lock_unuse(&(device->rLock)); wait_result = thread_block(); while(lkvi_use_lock_use_when_unused(&(device->rLock)) != 0) {}; } if (wait_result == THREAD_INTERRUPTED) break; } NOTE that the assertion of your intent to wait on that particular event occurred while you still held the lock (assuring you wouldn't miss the wakeup - assuming that the wakeup code actually takes the lock as well). ALSO NOTE: Both the assert_wait() functions and the thread_block() function return wait results. The assert_wait code knows your signal/abort state and your intentions with respect to letting this wait be interrupted. If you are already aborted, it won't even bother asserting your intention to wait (potentially giving the opportunity to be woken up to some other thread that isn't aborted). You only need to block (give up the CPU, if your assert_wait "took"). You also need to check for interruptible wait status. Otherwise, you're going to loop forever in the case that you were interrupted. --Jim _______________________________________________ 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: Wait Queues
by Jim Magee 05 Mar '03

05 Mar '03

On Wednesday, March 5, 2003, at 03:38 PM, Vivek Balasubramanyam wrote: I am definitely not giving up the CPU, although I expected that the assert_wait() function would put my thread to sleep. Are you saying that I need to call thread_block() in addition to assert_wait() in order to fall asleep? Correct. In Mach, blocking within the kernel is a two step process. You assert your intention to wait on a particular event, and then you block. Normally, you would unlock whatever you were using for synchronization after calling assert_wait() and before giving up the CPU (with thread_block()). This two stage approach has several advantages: 1. It allows you to use whatever form of synchronization you want (because you do the unlocking manually between the assert_wait() and the thread_block(). 2. It also allows you to check the return from assert_wait() to see if you really should block. For instance, you may be aborted because of a pending signal or thread termination, and the wait may have been interruptible, in which case the assert_wait() didn't have effect. So, no need to give up the CPU, just return the interrupted status so you can get to your signal handler quickly. 3. Once you unlock, but before you try to give up the CPU, the event may get posted (by another thread on another CPU, by a thread that preempts you on this CPU, or by an interrupt handler). By giving a window for this to happen before you commit to giving up the CPU, you may avoid unnecessary context switches. There isn't a specific need to use wait queues over any other kind of synchronization, since only one thread is ever in the queue. But I do need to use something that will let this thread sleep until a separate thread sends a wakeup signal (when the buffer goes from empty to non-empty). Note that you don't have to allocate your own wait_queues. There are a standard set of them for the system. If you just call assert_wait(), your event will be hashed to select one of the standard wait_queues to put you in. You only need your own wait_queue if you are going to use the wait_queue's native locking as your wider synchronization primitive (not available outside the osfmk component, but used by both Mach message queues, semaphores, and locksets) or if you need to manage sets of related waiters and event sources (like Mach portsets or BSD select sets, etc...). --Jim _______________________________________________ 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: Wait Queues
by Vivek Balasubramanyam 05 Mar '03

05 Mar '03

It's a software modem driver. Most of the driver was written using IOKit, but we have some logging and status monitoring functionality that I was hoping not to have to rewrite. We accomplished this on Linux by creating and feeding character devices from inside the driver, so that a user-level script could pipe those device files to a screen or regular file. I've taken that code, which uses wrapper functions (prefixed by 'lkvi') around anything OS-specific, and tried to rewrite the specific code to use BSD/mach equivalents. When I load the driver, a status char device gets created. If I try to do a "cat /dev/status_device", this locks the system in the device Read function, which includes this while loop: while (1) { /* synchronize with other reads */ while(lkvi_use_lock_use_when_unused(&(device->rLock)) != 0) {}; bytesAvailable = device->bufWrIdx - device->bufRdIdx; if (bytesAvailable < 0) bytesAvailable += device->bufSize; if ((device->buf != NULL) && ((bytesAvailable > 0) || (device->flags & SMD_OUTPUT_DEVICE_FLAG_TRAILING_EOF))) break; /* keep the lock since we'll need it anyway */ lkvi_use_lock_unuse(&(device->rLock)); /* SMD_PRINT_DEBUG_INFO (("Going to sleep")); */ lkvi_wait_queue_sleep_interruptible (&device->readQueue); /* SMD_PRINT_DEBUG_INFO (("Woken up")); */ } A function internal to the driver writes to device->buf. We use separate read and write locks, although in OS X there will only be one reader and one writer, and the circular buffer code is written so that reads and writes don't need to be atomic (writing only modifies the write pointer, and reading only modifies the read pointer). I also don't know much about character devices, so I assume that the read function must be all-or-nothing. This is why I wait in the first place. I am definitely not giving up the CPU, although I expected that the assert_wait() function would put my thread to sleep. Are you saying that I need to call thread_block() in addition to assert_wait() in order to fall asleep? There isn't a specific need to use wait queues over any other kind of synchronization, since only one thread is ever in the queue. But I do need to use something that will let this thread sleep until a separate thread sends a wakeup signal (when the buffer goes from empty to non-empty). Thanks for your help, Vivek On Wednesday, March 5, 2003, at 11:47 AM, Jim Magee wrote: On Wednesday, March 5, 2003, at 01:37 PM, Vivek Balasubramanyam wrote: Hi. I'm porting some driver code from Linux, and having trouble using the wait_queue API (in kern/wait_queue.h). I use "wq = wait_queue_alloc(SYNC_POLICY_FIFO);" to set things up, "wait_queue_assert_wait(&wq, NO_EVENT, THREAD_INTERRUPTIBLE)" to add my single thread to the queue, and wakeup_one to wake it up. It looks like my driver is locking the machine in a loop containing the assert_wait() call: while (1) { ..check if there's data ready to be processed.. ..if so, break ..else, assert_wait } The waiting thread is only woken up by me when new data is ready to be processed, and yet execution in this thread never leaves that >> loop. I haven't been able to find much information on wait_queues. Is there something obvious I'm missing about their initialization or >> use? What kind of driver are you porting. Usually, higher level synchronization is used in drivers (command gates in IOKit drivers, tsleep is BSD drivers, etc...). The wait_queue mechanism is pretty low-level for drivers. Wait queues alone are not enough to provide the synchronization that the code above needs. You must use some sort of lock to protect the atomicity of the "check if there's data, otherwise assert_wait" operation. Once you have firmly asserted your intention to wait, you can unlock whatever form of lock you chose and then volunteer to give up the CPU (when working at this low a level, that would usually be with thread_block()). It sounds like you aren't giving up the CPU (and therefore would only get taken off the CPU to be preempted by a realtime thread). --Jim _______________________________________________ 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: Wait Queues
by Jim Magee 05 Mar '03

05 Mar '03

On Wednesday, March 5, 2003, at 01:37 PM, Vivek Balasubramanyam wrote: Hi. I'm porting some driver code from Linux, and having trouble using the wait_queue API (in kern/wait_queue.h). I use "wq = wait_queue_alloc(SYNC_POLICY_FIFO);" to set things up, "wait_queue_assert_wait(&wq, NO_EVENT, THREAD_INTERRUPTIBLE)" to add my single thread to the queue, and wakeup_one to wake it up. It looks like my driver is locking the machine in a loop containing the assert_wait() call: while (1) { ..check if there's data ready to be processed.. ..if so, break ..else, assert_wait } The waiting thread is only woken up by me when new data is ready to be processed, and yet execution in this thread never leaves that loop. I haven't been able to find much information on wait_queues. Is there something obvious I'm missing about their initialization or use? What kind of driver are you porting. Usually, higher level synchronization is used in drivers (command gates in IOKit drivers, tsleep is BSD drivers, etc...). The wait_queue mechanism is pretty low-level for drivers. Wait queues alone are not enough to provide the synchronization that the code above needs. You must use some sort of lock to protect the atomicity of the "check if there's data, otherwise assert_wait" operation. Once you have firmly asserted your intention to wait, you can unlock whatever form of lock you chose and then volunteer to give up the CPU (when working at this low a level, that would usually be with thread_block()). It sounds like you aren't giving up the CPU (and therefore would only get taken off the CPU to be preempted by a realtime thread). --Jim _______________________________________________ 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

Wait Queues
by Vivek Balasubramanyam 05 Mar '03

05 Mar '03

Hi. I'm porting some driver code from Linux, and having trouble using the wait_queue API (in kern/wait_queue.h). I use "wq = wait_queue_alloc(SYNC_POLICY_FIFO);" to set things up, "wait_queue_assert_wait(&wq, NO_EVENT, THREAD_INTERRUPTIBLE)" to add my single thread to the queue, and wakeup_one to wake it up. It looks like my driver is locking the machine in a loop containing the assert_wait() call: while (1) { ..check if there's data ready to be processed.. ..if so, break ..else, assert_wait } The waiting thread is only woken up by me when new data is ready to be processed, and yet execution in this thread never leaves that loop. I haven't been able to find much information on wait_queues. Is there something obvious I'm missing about their initialization or use? Thanks, Vivek _______________________________________________ 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

Remote Kernel debugging
by Pev 04 Mar '03

04 Mar '03

Hi chaps! I'm looking at setting up a remote debug box for my dev machine (G4 PM) but I'm wondering what debug configurations are known to work. I don't have a second mac, so thats not a possibility for me, but I do have a few old PC's around. Has anyone had success using an x86 darwin box for remotely debugging a mac running darwin? I'm not sure if this is likly to be a big nono or not...! Thanks for any input, Dave Peverley Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com _______________________________________________ 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: NPROC / MAXUPRC
by Justin Walker 02 Mar '03

02 Mar '03

I don't believe there are any differences between the kernel for the server and client versions of Mac OS X, at least for this discussion. The server version includes a setting for maxproc of 2048 (in the SystemTuning Startup item) but that does not affect the per-user situation. The comments already made still hold. I can only check the client, so the server may actually have different settings, but the above sysctl setting is executed (in the client's startup item) if SERVER=YES in /etc/hostconfig. Regards, Justin On Saturday, Mar 1, 2003, at 15:35 US/Pacific, Peter Dyballa wrote: Hello! How is the situation with Mac OS X Server? Same low limits? Or motivating? (to buy ...) -- Greetings Pete _______________________________________________ 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. -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | When LuteFisk is outlawed | Only outlaws will have | LuteFisk *--------------------------------------*-------------------------------* _______________________________________________ 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