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