Multithreading problems

Marshall Crocker marshall at iconux.org
Thu Aug 3 16:34:24 UTC 2006


DKerns at westell.com wrote:
>
>
>   
>> thread1: locks semaphore, enters critical section, exits critical
>>    section, unlocks semaphore
>> thread 2: attempts to lock semaphore
>> thread 1: attempts to lock semaphore
>> deadlock
>>     
>
> you may not really have the situation that I'm interpreting from your
> description, but your describing an engineered deadlock!
>
> thread1: locks semaphore  := entering critical section
>
> if you really have a second "method" to "enter critical section", you've
> (re)designed the dinning philosophers problem where you have a
> lock/semaphore on each "fork".
>
> it's perfectly legit to have multiple threads attempt to lock the semaphore
> simultaneously. That is, in fact, the entire purpose of the semaphore.
>
> my $.02.
You are correct but I'm using a binary semaphore as a replacement for a 
mutex.  So essentially, no two threads should block at the same time 
while waiting to access the shared resource.  As soon as thread 1 
unlocks/increments the semaphore, the semaphore value should be 1 and so 
thread 2 should not block as the semaphore is non zero.

My next step is to try mutexes again.  If mutexes do work, then I think 
my problem will go away or at least I hope it will.



More information about the uClibc mailing list