• 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: Can pthread_cond_signal() block?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can pthread_cond_signal() block?


  • Subject: Re: Can pthread_cond_signal() block?
  • From: EJ Campbell <email@hidden>
  • Date: Sun, 03 Nov 2002 21:33:14 -0800

On Sunday, November 3, 2002, at 06:24 AM, kelly jacklin wrote:

[snip]
Neither. He is referring to the one in mach. See
/usr/include/mach/semaphore.h. The implementation of the pthread API for
pthread_cond_signal calls semaphre_signal_thread, but only after taking the
meta-lock on the condition variable (a spin-lock). So it is possible for
contention to occur (on MP system, not on UP) with this meta-lock (although
it is true that the window is very narrow, i.e. just the metalock which is
only held briefly).

I don't see how lock contention would only be a problem on MP systems. The LOCK() marco from pthread_internals.h appears to cause an immediate context switch on UP systems if it can't acquire the lock passed into it. So, when pthread_cond_signal_thread_np() calls LOCK(cond->lock), there's a possibility of a context switch if _pthread_cond_wait() is holding the lock. On MP systems, a context switch would be less likely since the LOCK() macro would spin for a while waiting for the lock.

Assuming that the semaphore_signal_thread call does not block, this would be
the way to go. Furthermore, the semaphore APIs provide "sticky"
synchronization (like all semaphores), so this should provide the
opportunity to remove the timeout spinning entirely.

This is what I'm now trying. I haven't traced through semaphore_signal() in enough detail to determine whether the call could possibly cause the same priority inversion as the others, but so far my initial testing hasn't shown any inversions.

Please (again) avoid the MPSemaphore calls. These are layered atop
pthreads, with a global-per-process termination lock and two pthread
construct usages for both the post and wait operations. Use as low as
possible. Believe it or not, the MP API is pretty high-level in its
implementation...

Yes, I absolutely agree. I was not advocating the use of MPSemaphore.
I just wasn't sure of exactly what was available on Mac OS X.

Thanks,
EJ
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: Can pthread_cond_signal() block? (From: kelly jacklin <email@hidden>)

  • Prev by Date: Re: Can pthread_cond_signal() block?
  • Next by Date: Re: Can pthread_cond_signal() block?
  • Previous by thread: Re: Can pthread_cond_signal() block?
  • Next by thread: Re: Can pthread_cond_signal() block?
  • Index(es):
    • Date
    • Thread