Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3A5F5A74.9AF4463A@troyxcd.com>
Date: Fri, 12 Jan 2001 11:26:44 -0800
From: Bill Hegardt <bill AT troyxcd DOT com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin AT sources DOT redhat DOT com
Subject: Serial I/O multi-thread safe?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


I have a cygwin application that opens /dev/com2 in binary mode for I/O
to a external device at 115200 bps. I'm
using cygwin 1.1.7 on Windows 2000 SP1. The serial I/O is done using
read() and write() in blocking mode.

If I write commands to the device and read the responses from the main
thread, all is well. But I need to
use separate threads (pthreads) one for writing and one for reading.
When I do this, the first command and response is ok, but the second
response includes more data than it should. In the multi-threaded
version, the read thread is normally
blocked on a read(). Here's the good single threaded output translated
to hex:

write : 01 01 ff 06 5e a5 ff ff 02 00

read: 04 0E 04 0A 01 ff 00

write: 01 01 ff 06 A0 a4 ff ff 00 2E

read: 04 0E 04 0A 01 ff 00


Using the multi-threaded application I get:

write : 01 01 ff 06 5e a5 ff ff 02 00

read: 04 0E 04 0A 01 ff 00

write: 01 01 ff 06 A0 a4 ff ff 00 2E

read: 04 0e 04 0a 01 ff 00 00 00 00 0e 04 0a 01 ff 00

That last read returned 16 bytes rather than 7. The first 7 are valid,
but the other 9 are bogus.

I've tried cygwin1.dll from V1.1.6, and V1.1.5 with the same results.
I've also checked with a serial line analyzer
to make sure that the extra bytes are not being sent on the wire. And I
have experimented with various tcsetaddr() settings
to no avail. The trace data above is output immediately after read()
completes, so a bug in the application code is unlikely.

I have set the serial port attributes as follows to let the read()
complete with less than a full buffer:
	serialPortAttributes.c_cc[VTIME]    = 0;   /* inter-character timer
unused */
	serialPortAttributes.c_cc[VMIN]     = 1;   /* blocking read until at
least 1 char received */

I should also mention that the multi-threaded application works fine on
RedHat Linux.

Any ideas?

Thanks

- Bill Hegardt

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple