I3ISU - Exercise 7: Thread Communication

Introduction
The purpose of this exercise is to learn the basics of thread communication using a message queue concept. This type of communication is a key stone in Event Driven Programming, which is typical for embedded systems.

Class: Message
Messages to passed around in the system using the message queue should inherit from the following class: The reason why the destructor must be declared virtual: The destructor must be virtual, so that the child objects inheriting from Message can delete the message when it is now longer needed.

Class: MsgQueue
The message queue itself will have multiple writers and a single reader, which means that it must have some kind of protection of the container holding the message. This protection must be implemented using conditionals. Another requirement of the message queue is a limitation of the number of messages allowed in the queue at one time. The class MsgQueue should look something like the following: Further requirements are: The container chosen for this exercise std::queue is used as container in this exercise. std::queue is a FIFO queue, and it is therefore well suited for this exercise. The implemented MsgQueue:
 * send is blocking if the internal queue is filled to the maximum denoted capacity.
 * receive is blocking if the queue is empty.
 * The container for holding incoming messages must be chosen from STL.

MsgQueue.hpp: MsgQueue.cpp:

Subexercise 2: Sending Data From One Thread to Another
The assignment in subexercise 2 is to create two threads Sender and Receiver, where Sender sends a message to Receiverevery second. The message to be sent should be an object of the type Point3D: The Receiverthread should continuously wait for new messages, and print the received x, y, z coordinates to console. The implemented thread functions:

Sender: Receiver:: The program is working. The output: New 3D point received: x=0, y=0, z=0 New 3D point received: x=1, y=1, z=1 New 3D point received: x=2, y=2, z=2 New 3D point received: x=3, y=3, z=3 New 3D point received: x=4, y=4, z=4 New 3D point received: x=5, y=5, z=5 New 3D point received: x=6, y=6, z=6 ... Questions to answer from the exercise The message is passed by passing a pointer to the created struct of the type Point3D. This means that the object is passed by reference and not by value, which implies that it is the receiving thread that must be responsible for the incoming message. It makes most sense if the receving thread is the owner of the object instance of class MsgQueue. It would be possible though to have it the other way around, but if you think of the message queue as in fact a message queue, then you would use it to send a message to a receiving thread. Anyone could send messages, but only one receiver would receive the messages. In theory though you could have the sending thread having ownership of the MsgQueue, and then have a number of worker threads process the sent received messages. In this scenario it makes no difference, and it is not required that any of the threads actually have ownership the MsgQueue, as long as they have a reference to it. The reference to the object instance of MsgQueue is passed as an argument to threads, when creating the threads. In the chosen design it would have been possible to pass an object of the type Point3D not inheriting from the Message class. This would require that that message type for the container std::queue in MsgQueue would have to be the struct Point3D.
 * Who is supposed to be responsible for disposing the incoming messages?
 * Who should the owner be of the object instance of class MsgQueue; Is it relevant in this particular scenario?
 * How are the threads brought to know about the object instance of MsgQueue?
 * In the chosen design struct Point3D inherits from class Message. What is the alternative to inheritance?

Subexercise 3: Enhancing the PCLS with Message Queues
The purpose of subexercise 3 is to reimplement the PLCS solution from I3ISU-Ex6: Thread Synchronization II using Message Queues and Messages to communicate between the cars and the door controller threads.

The following are must have requirements to the solution: Design of the car thread function The PLCS entry and exit guards have quite simple designs. Basically they should do the following: Pseudo Code:
 * A thread for the entry guard, one for the exit guard and one for each car instance.
 * Each thread's thread function, named handler here, must be implemented like the code example shown in the following listing:
 * The design and implementation must be able to handle multiple cars, but it is optional whether there is a maximum amount allowed at any time.

Questions to answer from the exercise
An event driver system is a system driven by events. This means that all processing and actions in the system are reactions to events. The PLCS system starts when cars requests access to parking lot. The waiting itself is implemented using sleep, but this sleep is inside the car thread itself, giving room for the other threads to run. In both solutions the shared data or messages are protected by mutex/conditionals. The clever thing added with the use of a message queue with embedded message queue protection, is that any thread can send messages without adding any data protection of it's own. The data protection is centralized in the MsgQueue class making it easier to reuse the message queue. An important benefit of the EDP approach, is that probing is avoided. Instead all processing and actions are driven/started on events. When the no event is triggered, no processing is needed.
 * What is an event driven system?
 * How and where do you start this event driven system? (Remember it is purely reactive!)
 * Explain your design choice in the specific situation where a given car is parked inside the carpark and waiting before leaving? Specifically how is the waiting situation handled?
 * Compare the original Mutex/Conditional solution to the Message Queue solution.
 * In which ways do they resemble each other? Consider stepwise what happens in the original code and what happens in your new implementation based on Message Queues.
 * What do you consider to be the most important benefit achieved by using the EDP approach? Elaborate.

Source Code

 * I3ISU-Exercise7: Subexercise 1&2, Source Code
 * I3ISU-Exercise7: Subexercise 3, Source Code