Multithreading problems

Rainer Weikusat rainer.weikusat at sncag.com
Thu Aug 3 17:45:31 UTC 2006


Marshall Crocker <marshall at iconux.org> writes:
> 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.

Your description of the situation so far is obviously impossible,
which means you must have described the situation wrongly regarding
some aspect.

If you're short control flow description is correct, a plausible
hypothesis would be that the sem_post done by thread 1 fails to unlock
the semaphore both threads try to acquire again afterwards for some
reason. You could, for instance, test this by using a loop like

	while ((rc = sem_trywait(&sem)) == -1
        	&& errno == EAGAIN) {
                fprintf(stderr, "thread %d failed to acquire sem\n",
                	(int)pthread_self());
                sched_yield();
	}

instead of a 'pure' sem_wait. If both threads fail to acquire the
semaphore, you should see output from both more or less randomly
intermixed.

        

                        
                 
                      



More information about the uClibc mailing list