Re: [Xenomai-core] [pipe.c] hairy synchronization -> "flush the output queue upon closure"

[Philippe Gerum <rpm@xenomai.org>]

Dmitry Adamushko wrote:
> yep, it's a problem since data may be client-dependent. In such a case, 
> for a new client old messages are just irrelevant. And xnpipe_release() 
> cleans up the queus but, well, does it too earlier.
> 
> so,
> 
> 1) should xnpipe_open_handler() and xnpipe_close_handler() be called 
> without holding a lock?
> 

Yes, it on purpose. I know this make things a bit trickier since this breaks the overall 
atomicity of the caller, but open/close hooks are expected to initiate/finalize 
communication sessions, and that may take an unbounded amount of time, so we definitely 
don't want to do this with the superlock being held.

> they are not used currently so I can't see.
> 
> I intend to make xnpipe_open() completely atomic.
> 
> 2) the cleaning of the queues (inq, outq) must take place atomically at 
> the time when XNPIPE_USER_CONN is dropped.
> 
> it's about something like
> 
> lock();
> 
> __clrbits(state->status,XNPIPE_USER_CONN);
> 
> // clean up all the queues
> 
> unlock();
> 
> it looks like we can't make the whole xnpipe_release() atomic because of 
> PREEMPT_RT + wake_up_interruptible_all() things, right? Or no.

You must _never_ _ever_ reschedule with the nucleus lock held; this is a major cause of 
jittery I recently stumbled upon that was induced by xnpipe_read_wait() at that time. So 
indeed, xnpipe_release() cannot be made atomic this way under a fully preemptible kernel.

> 
> 
> ---
> 
> Dmitry
> 


-- 

Philippe.