Multithreading problems

[John Clark]

DKerns at westell.com schrieb:
>
>
>   
>> 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.

Since we only have a schematic of the threads, and unfortunately I don't 
have time to really
'get into it', but there are more subtile ways to get a deadlock in 
multi threading. For example:

Thread 1:
     Lock semaphore 1
         Attempts to Lock semaphore 2 --- put on wait queue.

Thread 2:
    Lock semaphore 2
       Attempts to Lock semaphore 1   --- put on wait queue.

Now if these are really 'obvious' one would deal with them immediately, 
but with
a complex set of code, the fact that the two threads are trying to 
'cross' lock the
respective semaphores, leads to death. And also the code may 'work' 
because the
respective threads are busy 'elsewhere' when the other is going through 
the locked
code sequences.

This becomes problematic when using libc even with the pthreads safe 
versions of
the interfaces, if there is a point at which a long 'call' is done in 
the middle of a locked
segement of code.

John Clark



John Clark