Hi Marc,
the pending counter have to be used only by the semaphore thread (you
named it thread 02) and never by the other application threads (which
are calling sem_up and sem_down in archindep.h).
Please look at my last mail, because your program seems to call
semaphore_down (by thread 03) twice without semaphore_ups in between (by
other threads or by thread 03), which can be a cause for your observed
strange behaviors.
Regarding the pending variable, it is only used by the semaphore thread
and never evaluated or ever manipulated by the application threads
directly. So your proposed changes are incorrect.
See below the description of what the semaphore thread and the pending
bit is good for (extracted from l4/pkg/semaphore/lib/src/semaphore.c)
"This (semaphore) thread is used by other threads to block if they did
not get the semaphore. Threads call the semaphore thread , it enqueues
the caller to the semaphores wait queue (using the wait queue element
provided in the message buffer by the caller thread). The thread owning
the semaphore calls the semaphore thread to wakeup other threads waiting
on that semaphore. The semaphore thread then sends the reply message the
the waiting thread.
A separate thread is used to serialize the accesses to the wait queues
of the semaphores, thus no additional synchronization is necessary.
There is one tricky situation if the wakeup message for a semaphore is
received before the block message. This might happen if the thread
waiting on that semaphore is preemted by the thread releasing the
semaphore before it can send the message to the semaphore thread (see
l4semaphore_down()).
In this case the semaphore thread receives a wakeup message but no
thread is enqueued in the wait queue. In such situations, the wakeup
message is saved in l4semaphore::pending and the next block message is
replied immediately."
Bye,
Alex.
Marc CHALAND wrote:
> from Bjoern Doebel :
>
>> Are you just having a problem understanding the observed values or is there
>> a real problem that you are running into? If the latter, could you provide
>> a small example program so that we can reproduce it here?
>
> That's a real problem. I use several producer (08 and others) and one
> consumer (03) around a queue. I observed state 4, 5 and 6. This is
> anoying because semaphore_down exits as my queue is empty. At the
> begining I looked for some memory overflow into my code... But I found
> the scenario above which could explain this strange state.
>
> I tried a little change into archindep.h and the problem doesn't
> appear anymore. However, I find it very dirty and uncomplete because
> asm.h and generic should be also changed. As I don't know very well
> semaphore, maybe there are some case broken ?
>
> Marc
>
> --- include/archindep.h (revision 230)
> +++ include/archindep.h (working copy)
> @@ -54,7 +54,7 @@
> L4_INLINE int
> l4semaphore_down_timed(l4semaphore_t * sem, unsigned timeout)
> {
> - int old,tmp,ret;
> + int old,pending,tmp,ret;
> l4_umword_t dummy;
> l4_msgdope_t result;
>
> @@ -66,6 +66,7 @@
> do
> {
> old = sem->counter;
> + pending = sem->pending
> tmp = old - 1;
> }
> /* retry if someone else also modified the counter */
> @@ -73,7 +74,7 @@
> (l4_uint32_t)old, (l4_uint32_t)tmp));
>
>
> - if (tmp < 0)
> + if (pending || (tmp < 0))
> {
> /* we did not get the semaphore, block */
> ret = l4_ipc_call(l4semaphore_thread_l4_id,
>
> _______________________________________________
> l4-hackers mailing list
> l4-hackers@os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
--
Nöthnitzer Str. 46, Room 3087 Ph. +49 351 463 3 8534
D-01307 Dresden Fax +49 351 463 3 8255
[EMAIL PROTECTED]
key finger print: 5E79 31F6 F571 5FBA CF75 33FB AA34 4AF4 A633 25B3
_______________________________________________
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
