4 ms·

It is a similar concept like used in Go and Erlang. Don't use shared memory and locks, instead, send messages between processes. It works great with embedded r

It is a similar concept like used in Go and Erlang. Don't use shared memory and locks, instead, send messages between processes. It works great with embedded real time systems as well. It can be easier to get right than the alternative -- because without locks, the performance is more predictable. Less chance for race conditions and deadlocks as well. It is also basically the same thing as hooking up different processors with a bunch of serial ports. UARTs typically have a hardware ring buffer for send and receive. So basically, you simulate a bunch of separate processors all communicating. You could do it in hardware, or within software. Both work equally well.

pstuart 8y ago
Thanks for the detailed response.
mch82 8y ago
I think what you’re describing is one of the objectives of the Nerves Project (https://nerves-project.org https://nerves-project.org), which happens to include the BeagleBone as a target platform.
- etaioinshrdlu 8y ago
  Nerves doesn't look terribly amenable to realtime in design, however. About as amenable as running Node.js on linux. Not a great solution for strict timing requirements.
thebruce87m 8y ago
Would you not need to use locks for the ring buffers?
- learc83 8y ago
  Here's a good explanation from Linux Device Drivers, Third Edition. "When carefully implemented, a circular buffer requires no locking in the absence of multiple producers or consumers. The producer is the only thread that is allowed to modify the write index and the array location it points to. As long as the writer stores a new value into the buffer before updating the write index, the reader will always see a consistent view. The reader, in turn, is the only thread that can access the read index and the value it points to. With a bit of care to ensure that the two pointers do not overrun each other, the producer and the consumer can access the buffer concurrently with no race conditions."
  - thebruce87m 8y ago
    This would rely on an atomic update of the write index surely - is this guaranteed?
    - learc83 8y ago
      Yes most lock free thread safe paterns require the use of some atomic instructions. In the context of embeded real time systems you are generally targeting specific hardware, so you can make gurantees about the atomicity of specific instructions.
    - tlb 8y ago
      The requirement is generally that it can be written in a single instruction. This can fail on 32-bit processors like the x86 if you use a 64-bit index. For embedded work, it can fail on 8-bit processors if you use a 16-bit index. You can check, in C++, whether operations on a type are a single instruction. This might be true on an x84_64 and false on an x86: std::atomic<int64_t>::is_lock_free()

pstuart 8y ago

Thanks for the detailed response.

mch82 8y ago

I think what you’re describing is one of the objectives of the Nerves Project (https://nerves-project.org https://nerves-project.org), which happens to include the BeagleBone as a target platform.

etaioinshrdlu 8y ago
Nerves doesn't look terribly amenable to realtime in design, however. About as amenable as running Node.js on linux. Not a great solution for strict timing requirements.

thebruce87m 8y ago

Would you not need to use locks for the ring buffers?

learc83 8y ago
Here's a good explanation from Linux Device Drivers, Third Edition. "When carefully implemented, a circular buffer requires no locking in the absence of multiple producers or consumers. The producer is the only thread that is allowed to modify the write index and the array location it points to. As long as the writer stores a new value into the buffer before updating the write index, the reader will always see a consistent view. The reader, in turn, is the only thread that can access the read index and the value it points to. With a bit of care to ensure that the two pointers do not overrun each other, the producer and the consumer can access the buffer concurrently with no race conditions."
- thebruce87m 8y ago
  This would rely on an atomic update of the write index surely - is this guaranteed?
  - learc83 8y ago
    Yes most lock free thread safe paterns require the use of some atomic instructions. In the context of embeded real time systems you are generally targeting specific hardware, so you can make gurantees about the atomicity of specific instructions.
  - tlb 8y ago
    The requirement is generally that it can be written in a single instruction. This can fail on 32-bit processors like the x86 if you use a 64-bit index. For embedded work, it can fail on 8-bit processors if you use a 16-bit index. You can check, in C++, whether operations on a type are a single instruction. This might be true on an x84_64 and false on an x86: std::atomic<int64_t>::is_lock_free()