I am writing a simple C program (only running on a turnkey lamp box) that reads data from multiple com ports, translates it and sends it out another port. My plan is to start a thread for monitioring each port.

My question is, should I be concerned about receiving data from two ports similtaneously which would cause it to be written out at the same time.

Ex. ttyS0 and ttyS1 each receive a 5 byte message at the same time and then try and send the translated data out ttyS3.

My gut tells me shouldn't be a problem bc each thread will be getting a slice of processing time so the call to write out the data in theory could never happen at the same time but thought I would see if anyone else has more insight than I do.

Tks

I don't have insight, but I would suggest that you could develop a locking mechanism since, for example, all of a "chunk" of data may not be sent out of a port in one go. So, ttyS0 would lock the port for its own use, send its chunk out, and then unlock the port after using it. Of course, such port locking might already be a function of the operating system.

Are there some sort of 'messages'? If yes, you might want them not to get mixed, so you might wish to use some serialization.

I should have been more clear. The ports that I am reading from are locked. I am concerned about writing to the one output port from two threads at the same time. The order of the messages to the output port is not important. One thought was to create a thread for writing and queue up the messages for writing but if it's not possible to actually write them at the same time I would not go through the trouble.

I have several blog entries. They are very old, however serial programming and system V programming is similarly old, but well proven. They are all in the C language.

If you take the time, you'll see an entire architecture where there is a daemon that creates child processes which can then parse serial interfaces, and finally communicate with each other, as well as be monitored by the daemon to be restarted if they failed for some reason.

USB Receive and Rapid Parse, GPS Example

Creating a daemon to launch and monitor your processes

Using PIPES for Interprocess Communications

Select(2) and Why I Use It

How to kill those Zombies - by which I mean zombie processes.

Edit Addition:

• I don't necessarily prefer threads, but do use them. These examples are multiple processes and the performance was fine for several serial links
• Write your receiver and parser to be re-entrant and never make assumptions that you're going to get exactly an entire packet or frame during a single receive, in fact for me this rarely occurred.
• Yes it is helpful to minimize copying data, what I typically do is think about what I need to do and also realize that if I put information into a buffer, do not overwrite it or expire it, use a semaphore to protect it when various parts are running and operating on the data, that I do not need to copy. But ultimately there usually is a ton of data within a serial packet where some smaller amount is really needed. Such as my example of GPS, you probably want coordinates and time+date, but little else.

Just some added tips.

2 members found this post helpful.

Short writes aren't likely to be mixed with other writes (i.e. they are atomic). The only open points are the meaning of "short" and "likely". (It would be good to find some standard (e.g. POSIX) that clarifies this.)

My project requirements have grown to being able to handle data beginning with <STX> (0x02) and ending with <ETX> (0x03). I do not have the device that will be sending the data.

Any ideas on how to test?

I am developing in a virtual box (lamp), running my program, then opening up putty on my host OS using a pipe that is set up as com1 for the VM and configured to use CP437 so I can send alt+nnnn values. I suspect that putty is not sending characters as they are typed, but rather waiting until it sees <ETX>.

I've tried writing to /dev/ttyS0 using the following with no success

echo -n -e '\x02\x30\x48\x03' > /dev/ttyS0


Here are my flags I am setting when opening tty in my program.

newtio.c_oflag = 1;
newtio.c_lflag = 0;
newtio.c_cc[VTIME] = 0;
newtio.c_cc[VMIN] = 1;

doesn't threads have a means to sleep and wake them up, read from one port sleep to hold the information, maybe queue it to keep it from losing stuff, then wake up send, wake the other send, read sleep queue, read the other send wake that sleepy one send. kind of synchronicity. read 1 read 2, sleep 1, send 2 , wake 1 send 1 ~ complex as that sounds.

I have no need to thread but I got it working as expected using cfmakeraw();

...

My bad. design has changed. start daemon, spawn() now. no need for interprocess communication.