Trouble with semaphore library

[Alexander Boettcher]

Hi,

there are some state transitions in - at least between 1. state 3. state
- which can't occur, see below:

Marc CHALAND wrote:
> Hello,
> 
> I encounter strange problems with semaphore library from l4env. I use
> a vanillia revision 230 on an intel PIII architecture. After some
> debugging and tracing, I get the following scenarion :
> 
> 1. thread 03 of my process calls a semaphore down timed which then
> calls BLOCKTIMED IPC to semaphore thread 02. So semaphore structure is:
>  counter = -1
>  pending = 0
>  queue = 03
> 
> 2. thread 08 calls semaphore_up inline assembler code. Before IPC
> call, the semaphore structure is as follow :
>  counter = 0
>  pending = 0
>  queue = 03
> 
2.1 Now, Thread 02 (the semaphore thread) have to run, because this is
the only one which remove threads from the queue. Otherwise the 3. step
below isn't possible (empty queue, so thread 03 must be removed by
thread 02 from the queue).

> 3. Thread 03 gains the CPU after timeout and calls IPC RELEASETIMED :
>  counter = 1
>  pending = 0
>  queue = empty
Thread 03 increment the counter only if it gets really a timeout,
however the queue is already empty that means that thread 02 executed
between 2. and 3. step (2.1). Therefore Thread 03 should get a wakeup
IPC from Thread 02 instead of a timeout.

> 4. Thread 02 doesn't find thread into queue, so that pending is set to 1.
>  counter = 1
>  pending = 1
>  queue = empty
> 
> 5. Thread 03 calls semaphore_down. No IPC is called.
>  counter = 0
>  pending = 1
>  queue = empty
> 
> 6. Thread 03 calls semaphore_down again and IPC BLOCK is called. IPC
> awakes imediately 03 with a counter value of -1 and nobody into queue.
>  counter = -1
>  pending = 0
>  queue = empty
> 
> It seems to me that this state is not normal. Do you agree ? Is this
> scenario possible as I observe clearly state 4 5 and 6 ? What pending
> is for ?

In state 5. and 6. the same thread (thread 03) calls semaphore_down
twice without any semaphore_ups in between by other threads. Why the
thread 03 acquires the semaphore again when it has it already ? This
will cause strange behavior of your application/semaphore or will cause
dead locks.

Regards,

Alex.

-- 
boettcher at os.tu-dresden.de
key finger print: 5E79 31F6 F571 5FBA CF75  33FB AA34 4AF4 A633 25B3