[Pianod] wsgw hanging on RasPi; deadlock?

[Peter Li]

Heh, trying to get up-to-speed in realtime.

But yes I think the standard way is to use cond_wait with a condition 
variable protected by a shared mutex.  That way the mutex only protects 
the blocks where the condition variable is changed/set.  cond_wait 
provides for waiting without spinning. The mutex then is only 
locked/unlocked in the accepted way. Definitely more verbose than the 
shared mutex alone, but at the same time perhaps easier to reason about 
and read.

Semaphore would probably work, although I think it's a little 
nonstandard to have a semaphore with count 1 that more than 1 thread can 
decrement.

I think the barrier_wait is a good and concise solution; will give it a 
whirl.
P


On 02/25/2013 04:20 PM, Perette Barella wrote:
> Hmmm... you are correct.  Officially:
>       If the current thread holds the lock on mutex, then the
>       pthread_mutex_unlock() function unlocks mutex.
>
>       Calling pthread_mutex_unlock() with a mutex that the calling thread
>       does not hold will result in undefined behavior.
>
> Unofficially, that's how both pianod and pianobar handle play/pause, so despite behavior being technically undefined cross-thread mutex unlocks seems to work pretty reliably and exactly like we want them.
>
> Barrier waits or semaphores might be official solutions, but given it's worked in pianobar for years without trouble...
>
> Perette
>
>
> On 2013年02月25日, at 18:47, Peter Li wrote:
>
>> Yes, that's basically the idea, although I think with a semaphore you can wait without spinning?
>>
>> Although now that we're on the topic, I'm a bit confused by the mutex situation in wsgw as I thought the mutex is not supposed to be unlocked by a different thread than the one who locked it?  So maybe semaphore is more correct?
>>
>> P
> _______________________________________________
> Pianod mailing list
> Pianod at lists.deviousfish.com
> http://lists.deviousfish.com/listinfo.cgi/pianod-deviousfish.com