On 09/17/2013 03:31 PM, Jiří Zárevúcky wrote:
> On 17 September 2013 10:36, Martin Decky <[email protected]> wrote:
>
>> sleeper.h is used to implement the pipe queue. It's been a while since I
>>> implemented it, but I think the reason was that it's impossible (or at
>>> least very difficult) to implement the same structure using stuff from
>>> fibril_synch.h
>>>
>>
>> Could you please elaborate on this? The pipe queue is essentially a
>> producer/consumer (maybe with some twists, but still probably nothing
>> unheard of) and you are saying that it is very difficult to implement it
>> using standard synchronization primitives? How come
>> lib/c/generic/adt/prodcons.c is some 40 lines of code?
>>
>>
> Some of the reasons: In pipe, both readers and writers must wait for its
> counterpart.
I don't buy this one. Two condvars (one for each side) should suffice if
you want both sides to wait.
> Additionally, write must restart if corresponding read fails,
> and in such case it should be returned directly to the head of the writers
> queue (not possible with condvar), otherwise data would get out of order.
I've briefly looked at vfs_pipe.c, but couldn't find any situation where
condvars should not be sufficient. I think that f_wakeup/f_sleep could
even be directly replaced by condvar wait/signal respectively (plus a
little bookkeeping in the wait condition) and the code would work in the
same way as it is now.
So instead of
f_sleep(&a.sleeper);
You would write something like:
while (!a.signalled)
fibril_condvar_wait(&a.condvar, &pipe->mutex);
And instead of:
f_wakeup(&a.sleeper);
You would write:
a.signalled = true;
fibril_condvar_signal(&a.condvar);
Or (if you want to be very pedantic) set a waiting flag just before
waiting and write:
a.signalled = true;
if (a.waiting)
fibril_condvar_signal(&a.condvar);
You just then need to move the unlock calls a line or two below their
current position (so that the wait snippet above is called with the lock
held) and the rest of the code could IMO stay the same.
(I now see MartinD's email and I also basically agree with what he said)
Regards,
Martin Sucha
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
