Re: OS notifier preemption guarantees
Re: OS notifier preemption guarantees
- Subject: Re: OS notifier preemption guarantees
- From: Quinn <email@hidden>
- Date: Thu, 29 Apr 2004 12:57:45 +0100
At 16:47 -0400 28/4/04, Doug Hill wrote:
You basically need the pthread mutex support. Since I was using Carbon CFM
I didn't have access to that. In the end we rolled our own using certain
instructions that the PowerPC provides to form the building blocks for a
mutex.
Ouch. Don't do that, for three reasons.
1. MP critical sections act much like pthread mutexes, and you can
use them from a CFM application without jumping through any hoops.
[Just don't try to block at interrupt time on traditional Mac OS, but
you shouldn't need to do that as this problem only crops up on Mac OS
X.]
2. If MP critical sections don't work for you, you can always access
the Mach-O pthreads library from your CFM application. It's a bit of
extra work, but much less than reimplementing it yourself.
<
http://developer.apple.com/samplecode/CallMachOFramework/CallMachOFramework.html>
3. Using PowerPC atomic operations directly in your code is not
something we recommend.
DTS recommends that developers avoid using the PowerPC Load Reserved
and Store Conditional instructions. There are two reasons for this.
Firstly, these instructions are inherently processor-specific and
reduce the portability of your code. Secondly, the behavior of these
instructions varies between PowerPC CPU types. Accommodating all
these variations is tricky. These instructions do not provide much
utility beyond that provided by the Open Transport and
DriverServicesLib atomic routines, and Apple ensures that these
atomic routines are updated to do the right thing in all cases.
-- <
http://developer.apple.com/technotes/tn/tn1137.html>
For "Open Transport and DriverServicesLib", substitute "system services".
One nit pick @ Apple here is that I didn't find any of this OT weirdness
documented anywhere.
You mean like in the Carbon Specification...
With Carbon, one cannot assume that Open Transport deferred tasks
and notifier procedures run at deferred task level. On Mac OS X
they may be preempted by the main event loop or another Mac OS
thread.
-- <
http://developer.apple.com/documentation/Carbon/Reference/
Carbon_Spec_Porting/Open_Transport.html>
Or perhaps the Mac OS X release notes...
The runtime model and implementation of Open Transport on Mac OS X
are vastly different from those on OS 9. Because of this, Open
Transport notifiers, timer tasks, and deferred tasks are not
guaranteed to run to completion. They are not executed at a higher
priority than other existing threads [1]. What this means is that code
from the main event loop or another thread may preempt code running
from OT notifiers, OT timer tasks, or OT deferred tasks. To cope
with this, it is critical that you always protect your data either
by using atomic operations or by using
OTEnterNotifier()/OTLeaveNotifier(). Bracketing your critical
sections with OTEnterNotifier()/OTLeaveNotifier() is usually the
most convenient solution as this ensures that either the notifier or
the main event loop / cooperative thread has exclusive access to
common data.
-- <
http://developer.apple.com/documentation/ReleaseNotes/Carbon/
OpenTransport.html>
[1] This isn't true. They are run at a higher priority, it's just
that a higher priority doesn't guarantee run to completion semantics,
as explained below.
Or in a technote about threading...
Carbon's I/O completion model differs from traditional Mac OS in
that I/O completion routines do not "run to completion." Your I/O
completion routine is executed by a preemptive thread. While this
thread has a higher priority than the process's main thread, there
is no guarantee that the I/O completion thread won't be preempted by
that main thread. For example, if the I/O completion thread takes a
page fault, Mach could decide to run the process's main thread.
Moreover, if you're running on a multiprocessor system, the I/O
completion thread and your main thread could be running
simultaneously. If your application's synchronization model assumes
that I/O completion routines run to completion, this change in
system behavior can create bugs that are hard to reproduce, hard to
debug, and hard to fix.
-- <
http://developer.apple.com/technotes/tn/tn2028.html#
CarbonAndInterrupts>
I'll admit that Apple documentation often leads a lot to be desired,
but in this case I think we did a pretty good job.
S+E
--
Quinn "The Eskimo!" <
http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.