Re: OS notifier preemption guarantees
Re: OS notifier preemption guarantees
- Subject: Re: OS notifier preemption guarantees
- From: Doug Hill <email@hidden>
- Date: Wed, 28 Apr 2004 16:47:56 -0400
>
I am installing a notifier proc on an OT endpoint, and I observed
>
that the notifier fires on a separate preemptive thread (which I
>
expected).
>
>
I also observed a case in which the notifier is preempted and control
>
is returned to the main thread before the notifier completes, which I
>
did not expect; I expected the notifier to be atomic as far as the
>
main thread is concerned, and the fact that it isn't causes
>
interesting problems in my code: is sets up a race condition where
>
while the notifier is active the main thread sometimes closes the
>
endpoint and deletes the C++ object that's associated with the
>
endpoint, causing the notifier to crash when it gets time later.
>
>
How should I deal with this? The best I can come up with is:
>
Welcome to OT on OS X! I spent a great deal of time in our product removing
assumptions that the OT notifier code will run to completion before any
other app. threads get time [as it used to on OS 9].
Note that the Powerplant Networking stuff is also /totally/ broken. e.g. the
WaitForCompletion() stuff with the Timer Tasks to do timeouts. Another team
member spent a few weeks adding semaphores to the Powerplant "Interrupt
Safe" classes. [However, we only ran into problems when our FTP server, FTP
Client, and Email code based on Powerplant OT networking was put under
stress testing].
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. In fact I looked at how Darwin implements them and they use the same
PPC instructions as one would expect. I don't recall where I found my
starting point but you might try to Google "lightweight mutex OS X". Email
me if you still can't find the reference. The PPC 601 Manual has an
appendix that covers the instructions too.
One nit pick @ Apple here is that I didn't find any of this OT weirdness
documented anywhere. Granted we're supposed to be using BSD sockets or
CFNetwork now, but a lot of us have very large applications where market and
business concerns do not allow us to re-write code. A technote explaining
how broken OT is under Carbon on OS X would have been a big help [my
apologies if there is one I missed!]
I would level same complaint at Metrowerks as well which has shipped CW9 and
a) doesn't provide networking in the PP OS X nor b) alerted anyone to the
very large problems using PP networking on OS X.
</venting>
-d
--
Doug Hill
Group Logic Inc.
1110 N. Glebe Rd
Suite 850
Arlington, VA 22201
fon: 703.528.1555
fax: 703.527.2567
email: email@hidden
>
main thread:
>
>
acquire lock
>
close the provider
>
dispose the C++ object
>
release lock
>
>
notifier:
>
>
acquire lock
>
if provider hasn't been closed then
>
do stuff
>
release lock
>
>
which is fine except that I don't know how to write the "if provider
>
hasn't been closed"part.
>
>
meeroh
>
--
>
>
<http://web.meeroh.org/> | KB1FMP
>
>
"And when I have understanding of computers, I shall be
>
the supreme being!" -- Evil, "Time Bandits"
>
_______________________________________________
>
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.
_______________________________________________
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.