ISU E7 - Message Queue


Exercise 1 Creating a message queue

To have something tangible for our upcoming message queue, we start out creating the class Message. This class will from now on serve as the basis (parent) of all messages that are passed around in our system. In other words all other messages must inherit from this class. Remember that the destructor must be virtual.
Why is this last bit very important? Explain!

The destructor of the Message class is virtual because this class is the parent class of all our messages but when a message gets out of scope or we want to delete a message then we want to use the destructor of our implementation (child class) to make sure we clean up properly.



Next we create the MsgQueue class itself. One of its aggregated variables is a container; this container is the one that will hold all incoming messages, before the receiving thread processes them one at a time.
We must remember that the usage scenario is one where we have multiple writers and a single reader, which is why appropriate protection is vital. This protection must be handled via the use of conditionals. Furthermore, as specified in the constructor call, a limit is set on the number of messages in our queue. Again this is to be handled as well via the use of the aforementioned conditionals.




Further demands:
  • send() is blocking if the internal queue is filled to the maximum denoted capacity.
  • receive() is likewise blocking if the queue is empty.
As stated earlier the incoming message must be placed in a container, which one to choose?

We have chosen to use a queue STL.

MsgQueue.h:


MsgQueue.cpp:




Then create two threads Sender and Receiver, where the Sender creates an object Point3D every second or so and sends it to Receiver. The Receiver should continuously wait for new messages and, on reception, print the x, y, and z coordinates of the received Point3D object to the console.



Create a function main() that creates a message queue and then spawns the two said threads running Sender and Receiver respectively that communicate via this message queue.
Test your system - does the receiver thread receive what the sender sends?

Main.cpp:





Execution:



Questions to answer:
  • Who is supposed to be responsible for disposing of the incoming messages?
    • receiver
  • Who should be the owner of the object instance of class MsgQueue. Is it relevant in this particular scenario?
    • All recievers should own a MsgQueue, since it makes sence to write a queue if the receiver is terminated.
  • How are the threads brought to know about the object instance of MsgQueue?
    • A MsgQueue is globally made, send to threads as parameter.
  • In the chosen design struct Point3D inherits from class Message. What is the alternative to inheritance?
    • Use templates
    • Use an array

Exercise 3 Enhancing the PCLS with Message Queues

Reimplement your PCLS solution using Message Queues and thus messages as a means to communicate between car thread and door controller thread.
The following are must have requirement for your solution:
  • A thread for the entry guard, one for the exit guard and for each car instance.
  • Each thread's thread function, named handler() here, must be implemented like the code example shown in Listing 3.1.
  • Your design and implementation must be able to handle multiple cars, but it is optional whether there is a maximum amount allowed in at any given time.

Parkinglot.cpp:






Note: Initiation(Main) is the same.

Inter Thread Communication

Before you start any coding what so ever, you must make either a create sequence or a state
chart diagram! This diagram must be depicted in your solution, and you must state why you
chose this particular diagram. Furthermore your main loop in every thread you have must
look like the code1 shown in listing 3.1 !



Questions to answer:
  • What is an event driven system?
    • Listen for events and reacts
  • How and where do you start this event driven system? (remember it is purely reactive!)
    • When a car arrives at the entry and wants to enter.
  • 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?
    • It sends a message to the exitguard, and is block until it receives a confirm.
  • 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.
      • The two solutions is far from different. Both solutions make use of conditionals in order to ensure no concurrency problems. But the solution with message queues seems to be easier to implement because the message queues have the responsibility of locking mechanisms and therefore the message queue works as an abstraction level. The developer have does not have to concern about concurrency-related issues
    • What do you consider to be the most important benefit achieved by using the EDP approach, elaborate.
      • By using EDP is that it reduces the need for critical sections e.g. mutex and semaphores. If we compare our two solutions we have only one mutex and one conditional in our EDP-solution.

2 kommentarer:

  1. Denne kommentar er fjernet af forfatteren.

    SvarSlet
  2. Key points of this exercise is to:
    Learn how an event driven system works.
    Learn how to handle different types of messages.
    Learn how to communicate between threads.

    The first two exercises looks like it should. there isn't much to say about them.
    The third exercise looks ok but there are a few things to mention.

    first of all, where is your SD or flowchart diagram? this helps to get an overview of the exercise.

    You have made handler functions in the entry and exit threads and that makes the code easier to read. Your car driver should also have a handler, so it would read a message, and use the handler to act on the message.
    The point of the exercise is to switch on the id you recieves together with the message. You have implemented your car thread in a way that will never check the ID you receive from the entry/exit gate, instead you just switch depending on which state your carthread is already in.

    You have only 1 CarMsgQueue that is made global.
    You are supposed to make messagequeue for each carthread, since each car must be able to read it's own messages. If you creates more than one car with your implementation, each car will read a random message, and a car waiting in the queue could receive a massage allowing it to drive in again(?).
    You should have made a queue for each car, by creating it as the first thing in the carthread.
    Because you have implemented your carMessageHandler the way you have, the program might work "as intended", but only because you never check what message is incoming.

    You dont need to send the msgQueues as arguments to the threads, as you have made them global the threads have direct access to them.

    You have completed the exercise

    SvarSlet