0

I am wondering if i can use a semaphore and mutex with Linux OS programmed in C++ with the API semaphore.h.

I am not yet in code development/writing phase but the goal is to have a readout on a receiver which sends out asynchronous binary data at a baud rate of 115,200. Then this data must be relayed into a modem as fast as possible.

I was thinking about using perhaps a RTOS but I have no knowledge about bootloaders and how to get Linux or any other OS on a chip or embedded environment.

Would it be possible to write these read and write functions in a separate thread interconnected by signals and pipes, with the addition of semaphore's?

The semaphores could be required when I have to format the received data in another format, parse only the required strings, or have to modify them mathematically. Before sending them out.

Is it possible to receive the benefits of semaphores when using a non-RTOS? I have only seen these being applied in cooperation with RTOS's.

Clifford
  • 88,407
  • 13
  • 85
  • 165
iBeyondPower
  • 357
  • 1
  • 5
  • 8
  • It is not clear how you implementation needs signals, pipes *and* semaphores; or even why it needs to be multi-threaded give sufficient buffering, but if you want to port your POSIX code later to an RTOS, you are best using mechanisms that exist in both. – Clifford May 08 '15 at 11:52

2 Answers2

0

POSIX semaphores are no less relevant to synchronisation in multi-threaded Linux applications than RTOS semaphores in an embedded application.

Clifford
  • 88,407
  • 13
  • 85
  • 165
0

Think about what 115200 as a baudrate means - this is 11520 characters (assuming 8N1) per second or about 86.8 usec per character. Now the Linux OS is a fickle thing for real time but we for sure won't have trouble at about 1 millisecond granularity assuming we've got a stock 1000hz kernel, which is about 11.5 times that - provided you set your scheduler. Further - in a way, this is the worst case latency - batched writes of characters together will have nearly perfect character-to-character latencies, assuming you can keep the outgoing buffer filled.

Now answer this question: what is tolerable to your application? Depending on the answer, you will have to consider different things - from the real-time patches for linux - to hybrid Xenomai/RTAI to a full RTOS like RTEMS. With my current understanding of your situation, I'd say it's probably enough to use a 1000hz kernel.

The linux serial filedescriptors can be written to and read from in different threads at the same time with no issues. You can separate these tasks to different threads or use nonblocking IO in exchange for insignificant latency as long as your processing is light - this can avoid context switches and that's good because those are slow. In other words you don't need to bring in semaphores if using threads or nonblocking mode.

And finally - semaphores are in practically all OS's

Jason Newton
  • 1,201
  • 9
  • 13
  • Post your first paragraph as a comment - it does not belong in an answer. – Clifford May 08 '15 at 17:58
  • The problem of streaming data at 115200 is not generally as load-heavy as you suggest; the granularity of the system clock is irrelevant, a serial UART with either DMA or a hardware FIFO buffer will present far lower CPU load and cam be serviced at a significantly lower rate at the application. – Clifford May 08 '15 at 18:08
  • @Clifford a full buffer may be intolerable latency to his application and UART buffers are all over the place - from 8 to 64 characters; I've also seen people have problems using a 100hz kernel on serial devices so I don't think it's a good idea for him; you mind find this relevant: http://stackoverflow.com/questions/13126138/low-latency-serial-communication-on-linux – Jason Newton May 09 '15 at 00:12