communication on autosys

Buffer

Mon, 13 Feb 2017 00:00:00 +0000

Uncoupled communication between two objects which run in separate threads can be achieved through buffers. A buffer is placed between the two communicating objects and can store a single element. There are different types of buffers depending on the context in which they are used but they all share the same interface which supplies two functions: put and get. Three different variations have to be considered:

fully synchronous: put and get both block the calling thread. The put call blocks when there is data already present in the buffer and get blocks when called on an empty buffer. Calling get empties the buffer.
continuous write: get blocks on an empty buffer, put doesn’t block but overwrites the current data (if present) in the buffer. The get call moves the data out of the buffer, meaning that all data is only read once.
continuous read: the buffer is initialised with a default value. Neither put nor get block. The data in the buffer can be re-read any number of times and can always be overwritten.

The fully synchronous and continuous write buffers both store a unique element which is removed from the buffer as soon as get is called. Because of this the internal storage is implemented with a std::unique_ptr. For the continuous read buffer this is not the case so it just stores the element by value because the buffer is never empty.

Channel

Mon, 13 Feb 2017 00:00:00 +0000

A channel is a thread-safe queue which uses semaphores to synchronize access. The underlying queue in this implementation is the C++ std::queue container. It uses two semaphores sem_free_spaces_ to count the free spaces in the queue and avoid overflow and sem_size_ to count the elements in the queue and prevent underflow. In addition a std::mutex is used to synchronize access to the queue.

To enqueue an element to the channel the sem_free_spaces_ semaphore is first decremented which will block on a full queue and then increments the sem_size_ semaphore after adding the element to the queue.

Dequeuing works the opposite way by first decrementing sem_size_ to block on an empty queue.

In addition the « operator has been overloaded to move items into the channel or out of it. It also supports moving an item directly from one channel to another.

A destroy function is used to notify waiting threads to shutdown the program. For clarity this is implemented only in a rudimentary way. For full functionality it must be defined what shall happen when the reader blocks on an empty queue and when the writer blocks on a full queue while the system is to be shut down. There are several solutions for this problem which shall be discussed in a further post.

Fully Synchronous

Mon, 13 Feb 2017 00:00:00 +0000

A buffer is used for communication between objects which run in different threads. A buffer wraps some shared memory or a unique pointer thereto. The buffer may be accessed by the two communication partners via reference to the buffer which is initialized via constructor argument.

A buffer is a single block of memory for a message (or unique pointer) and messages are not queued. Check out the channel if you need communication via a message queue. There are different ways to use a buffer for communication. Either it is ensured that the producer waits until the latest message has been read by the consumer, and the consumer waits until a new message has been provided by the producer. This is called fully synchronous buffer (fsb). No messages are lost or repeatedly read.

Another possibility is the contiuous write buffer, where the producer does not wait for the consumer to read and overwrites messages. Messages may be lost in this case if the consumer read slower than the producer writes. The contiuous asynchronous buffer (cab) does not wait on either side. The consumer may read the same message if no new messages are provided by the producer.

This code example shows how the full_sync_buffer is used. Three thread objects are created (producer, broker, consumer). A message is created in the producer, which is passed on to the broker which passes it on to the consumer. Two buffers are used to realize this (lines 108 and 109), which are given to the thread objects via constructor argument (lines 110 - 112). Broker and Consumer block on the get-call and wait for the message to arrive. The Producer blocks on the put-call until the receiver is ready to receive (i.e. until the buffer is empty). This way the communication is synchronized.

Once the broker has passed on the message, the producer could go on and send the next message to the broker (not shown in the code) while the consumer might still be busy with the first message. The producer needs to create new memory for each message. A unique pointer to the message is passed on between the communication partners. Be aware at this point, that the new call will take a lot of time if used frequently. It is a good idea to use a memory pool at this place.

The memory of the message is automatically cleaned up by the use of a unique pointer. This happens in the moment the unique pointer in the consumer is overwritten by the next message.

Observer

Mon, 13 Feb 2017 00:00:00 +0000

The very traditional way to implement the observer pattern is by using polymorphism. You have to derive the class which contains your callback function from an observer base class, and you have to overwrite the function notify(). This is done in the first code C++03 sample you see here. Create a ConcreteObserver, derived from Observer, and fill in your personal notify function. The subject stores all ConcreteObservers in a vector. When something changes in the Subject (e.g. an event occurs) the Subject calls notify_oberserver() and all concrete observers get their notify called.

This has some drawback, of course. You might not want to derive your class from Observer or you might not want to call your callback function notify(). Of course, there are a lot of workarounds: function pointers, wrapped function pointers, delegates etc.

But look at the C++11 code. Here there is no Observer object. There is just a functor (a class which has its operator() implemented). This will be your callback object. It must not be derived from anything. You can name it however you want. The functor simply has to be registered with the subject (register_observers()) and it will be notified respectively.

In C++11 you can even do the following: Suppose you already have a member function which you want to have registered with the subject. Let it be some function callme() of some class B. B must not even be a functor. You can register callme() by doing

B b; // create an object of your class
subject14.register_observer( [&] ( ) { b.callme(); }   ); // register your member function

The lambda which is used here may be used as an argument for register_observer, also. This way you may register arbitrary functions, provided they have the correct signature.

Thread Control

Mon, 13 Feb 2017 00:00:00 +0000

How to stop a thread.

It is a nice idea to create a functor (overload operator()) and pass a functor object to a thread. The operator()() (line 9) should generally contain a while loop (event loop)(line 10). To be able to stop the while loop from the outside, one can use a member variable of the functor, e.g. bool IsStopped or bool IsRunning (line 15). The loop would then look like this

while(IsRunning){...}

Another thread (e.g. the main thread) could then set the flag to true (or false) (line 23) and this will end the while loop.

In order to make this work, the functor object has to be passed as a reference to the thread (line 20).

thread(std::ref(thread01));

If you need more sophisticated communication between threads, you should use the buffer or channel which are described in separate posts.