• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: OTMP with an Async Notifier Model
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OTMP with an Async Notifier Model


  • Subject: Re: OTMP with an Async Notifier Model
  • From: Quinn <email@hidden>
  • Date: Tue, 10 Feb 2004 13:37:12 +0000

At 19:52 -0800 9/2/04, Bob Cook wrote:
Not that I'm aware of. There should be, it can be beneficial.

I disagree. Running your threads on two processors makes these sorts of problems happen more often. Exactly the same problem can occur on a single processor machine if the OS happens to schedule your threads in exactly the wrong way.

I suspect that although ::Enqueue() is "interrupt safe" in Carbon, its not thread safe, which is the source of the PowerPlant woes.

I don't think so. As real hardware interrupts are never delivered outside of the kernel on Mac OS X, all Carbon 'interrupts' are actually being executed by a thread. Thus, interrupt safe translates to thread safe on Mac OS X. This is discussed in detail in the "Carbon and Interrupts" section of DTS Technote 2028 "Threading Architectures".

<http://developer.apple.com/technotes/tn/tn2028.html>

A few strategic additions of ::MPEnter[Exit]CriticalRegion() around the data structures shared between the notifier and the PowerPlant application worked for my buddy.

Right. This is a critical (ahem) point. Because Carbon runs your 'interrupts' on a thread, there's no guarantee that interrupts will run to completion. To quote TN 2028.

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.

The Mac OS 9 side of OTMP has problems like this, which is why you should only use it on Mac OS 9. On Mac OS X, you should call OT directly instead. The OTMPX routines do this switching for you, calling OTMP on Mac OS 9 and OT on Mac OS X.

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.

References: 
 >Re: OTMP with an Async Notifier Model (From: Bob Cook <email@hidden>)

  • Prev by Date: Re: OTMP with an Async Notifier Model
  • Next by Date: gethostbyname problem with XCode ?
  • Previous by thread: Re: OTMP with an Async Notifier Model
  • Next by thread: URLManager progress window
  • Index(es):
    • Date
    • Thread