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 :
- 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
- 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).
- 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.
- Thread 02 doesn't find thread into queue, so that pending is set to 1.
counter = 1 pending = 1 queue = empty
- Thread 03 calls semaphore_down. No IPC is called.
counter = 0 pending = 1 queue = empty
- 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.