From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <437DAA54.5060408@domain.hid> Date: Fri, 18 Nov 2005 11:17:56 +0100 From: Philippe Gerum MIME-Version: 1.0 Subject: Re: [Xenomai-core] [pipe.c] hairy synchronization -> "flush the output queue upon closure" References: <437DA982.3040603@domain.hid> In-Reply-To: <437DA982.3040603@domain.hid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philippe Gerum Cc: xenomai@xenomai.org Philippe Gerum wrote: > 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 "reschedule" in the Linux sense here; entering Xenomai's rescheduling procedure with the superlock held is of course perfectly valid. 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.