utility 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.

Parameter Handling

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

Algorithms often need parameters which need to be adjusted while testing the program. Instead of writing all parameters in a .h-file which requires that the code has to be compiled after each change, we propose a method which allows parameter handling during runtime in a uniform manner.

A basic requirement for this is, that the parameters may still be used in equations, calculations and conditions without having to deal with bloatware method calls.

This code sample shows how to wrap atomic types such that they will still feel like an atomic type. However, because your parameters are inside a wrapper, you may now manipulate all your parameters via this wrapper class. For example, you may store all parameters in a list, save them to a file, remote access them with a browser and so on.

Semaphore

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

Object-oriented semaphores are not part of the C++ standard at this point. However, it is possible to implement a semaphore class using a mutex and a condition variable both of which where added to the standard in C++11.

For the implementation shown on this website the function names where derived from the POSIX semaphores. The post function increases the count of the semaphore and notifies a thread that might be waiting on the semaphore if its count is at zero. The wait function decreases the semaphore count and blocks if the count reaches zero. Any thread calling wait when the count is at zero waits on the condition variable until notified that the count has increased.

A variation on this function is the try_wait function which does not block but simply return its success in acquiring the semaphore in the form of a bool.

Singleton

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

A singleton is a class which controls the number of objects to be created from this class. Most often there shall be just a single object from a certain type. The basic principle to reach this is to limit the access to the constructor, i.e. making it private. There is a static function which allowes a single point of access to the single object.

Controversial discussion

There is a controversial discussion if a singleton is good design. The main critique is that it is reachable from any scope, thus appearing as a global variable. It is also not trivial to make it thread-safe (pre C++11). Destruction of a singleton is another issue. Also, lazy initialization might not be what you want in a time-critical system. I personally suggest in reactive time-critical systems to allocate your resources at start-up time if possible. This will guarantee by design that there is only a certain number of objects of a certain type. Also the initialization order may be established easliy. The objects shall communicate via appropriate communication channels.

Issues

There are a couple of issues to think about when deciding to use a singleton and choosing the right implementation.

threadsafety of a singleton. There is the DCLP (double checked locking pattern) [1] to make the original GOF singleton [2] thread-safe. As recovered several years later, this may fail under certain circumstances [3]. In C++11 there is a thread-safe implementation due to a new memory model. The Meyers Singleton [5] is also thread-safe in C++11.
destruction. The original GOF singleton cannot be destructed. At the end of the program it doesn´t free its resources. The Meyers Singletons destructor is called at the programs end. If you need to destroy a singleton during runtime and re-create it later, the phoenix singleton [6] comes in handy.

References

[1] D.C. Schmidt, T.Harrison; Double-Checked Locking; Pattern Languages of Program Design 3, 1997
[2] E.Gamma, R.Johnson, R.Helm, J.Vlissides; Design Pattern; Prentice Hall 1994
[3] S.Meyers, A.Alexandrescu; C++ and the Perils of Double-Checked Locking; 2004
[4] H.Sutter; herbsutter.com
[5] S.Meyers; More Effective C++; 1996
[6] A.Alexandrescu; Modern C++ Design, Addison-Wesley, 2001