Re: OS notifier preemption guarantees
Re: OS notifier preemption guarantees
- Subject: Re: OS notifier preemption guarantees
- From: Doug Hill <email@hidden>
- Date: Thu, 29 Apr 2004 10:26:38 -0400
>
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.]
They didn't for some reason although I didn't do this work so I can't really
give more info as to why not...
>
>
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.h
>
tml>
>
yes, that was an option but in reality it was less work to just roll our own
using the starting point someone else provided on the net.
>
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>
>
well, don't know what to tell you here other than it works on G3 iMac
through G5 dual processor. Point taken on future hardware.
>
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...
yeah, yeah, ok, it's splattered across the entire Carbon documentation and
release notes. I just think a tech. note in the /networking/ section would
have made more sense and been easier to find. But that's me :)
>
>
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>
>
>
[snip]
>
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.
yes, just in the wrong place, IMO.
-d
--
"Weaseling out of things is what separates us from the animals.
Well, except the weasel."
- Homer J Simpson
_______________________________________________
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.