This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
RE: Race conditions in serial_select
- From: Jay Foster <jay at systech dot com>
- To: 'Andrew Lunn' <andrew at lunn dot ch>, "Gaer, A." <Andreas dot Gaer at baslerweb dot com>
- Cc: Jay Foster <jay at systech dot com>, ecos-patches at ecos dot sourceware dot org
- Date: Mon, 27 Jun 2005 13:11:39 -0700
- Subject: RE: Race conditions in serial_select
In the existing code, it looks like cbuf is assigned either the value
&chan->in_cbuf or &chan->out_cbuf, depending on the value of 'which'
(CYG_FREAD or CYG_FWRITE). In the proposed patch, it is always assigned the
value &chan->in_cbuf. This probably is not what was intended.
Jay
-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch]
Sent: Monday, June 27, 2005 12:53 PM
To: Gaer, A.
Cc: 'Jay Foster'; ecos-patches@ecos.sourceware.org
Subject: Re: Race conditions in serial_select
On Tue, Jun 21, 2005 at 05:01:29PM +0200, Gaer, A. wrote:
> Hello!
>
> As the DSR IMHO shouldn't try to accquire the mutex lock anyway, I would
> guess that it is save to do the locking in the proposed way. But I must
> admit that I intended to do it exactly the other way around like it was
done
> in all the other functions of the serial.c file, simply to keep the logic
a
> bit consistent. Don't ask me why I got it wrong, I must have been
completely
> blind that afternoon. Sorry.
>
> I can resend the patch with the locks swapped, if this is wanted.
>
> As I understand it, the mutex lock is used to synchronize access to the
> read/write buffers from concurrent threads. As the logic of the select
> depends on the consitency of the buffers during it's exectution, I would
say
> the mutex lock is neccessary. Though I can't imagine any usecase where the
> serial select and read/write calls are placed into different threads - but
> who knows.
How does the attacted patch look?
Andrew