Øvelse 7

Exercise 1 - Creating a message queue

The basis class Message was implementet as follow in af headerfile:









The MsgQueue class was implementet as follow in the headerfile:






















The functions of MsgQueue was implementet as follow:
















































We use a conditional signal and a mutex between the send and receive functions. Furthermore we use the STL container queue, which works as a FIFO queue, so we can put QueueItems in a queue and delete them when needed.

Exercise 2 - Sending data from one thread to another

The Main file was implentet as follow:


























When we executes the program we see the following:


We see that the QueueItem is added every second to the FIFO queue, until it's full. The the receiver starts to remove a QueueItem, so a new QueueItem can get into the FIFO.

Questions to answer:

  • Remember 
    that the destructor must be virtual. 


    Why is this last bit very important?
The class MsgQueue is a inheritance from Message, and the destructor must be virtual because the MsgQueue as a "child" uses the destructor from Message; the "parent".
  • Who is supposed to be responsible for disposing of the incoming messages?
The receiver is disposing the incoming messages, and delete them when there is to many in the FIFO queue. The sender do not know anything about the messages; it only sends them to the receiver.
  • Who should be the owner of the object instance of class MsgQueue; Is it relevant in this particular scenario?
The reciver should be the owner of the MsgQueue class, since it destroys the msg, which is the created message.
  • How are the threads brought to know about the object instance of MsgQueue?
It is via the void pointer, which containing data about the Message object.
  • In the chosen design struct Point3D inherits from class Message. What is the alternative to inheritance?
We could write a Point3D class instead with the same functions as the Message header-file.

Exercise 3 - Enhancing the PCLS with Message Queues

We have implentet the code for the PCLS as follow:




































































































































When we executes the program, we see as follow:


Questions to answer:

  • What is an event driven system?
Its a systemthat reacts different on different events, that occurs in the program.
  • How and where do you start this event driven system? (remember it is purely reactive!)
When a car threadis created the system starts to react on the specific car thread.
  • 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?
The car thread is waiting for some free space in the parking system, before it enters.
  • 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.
In the Mutex/Conditional solution the threads communicates via the Mutexes and conditional signals. In this one we use messages to communicate via the threads. Personally we think that the solution with the conditional signals was easier to make, but in more complex system the messages might be better.
  • What do you consider to be the most important benefit achieved by using the EDP approach, elaborate.
Its easier to see where the failures occurs.


1 kommentar:

  1. Main Goals:
    Learning basics of messaging between threads / Event driven programming
    - Using message queue
    - create a visual overview (state/sequence-diagram) of the desired functionality, and implement it.

    In the implementation of MsgQueue you make a delete on the Queue which ISN't located on the heap??
    Mutex and conditionals are being created globally, and lead to potentially very bad behaviour.
    It might not have been experienced in your test program because of broadcasts, but it leads to problems, which Søren Hansen explained earlier.

    Its bad programming practice to let the entryGuardHandler sleep for one second.

    Entry and exit queues are being created globally, instead of implemented in each class.

    The sequence/state diagram is missing.

    All in all you barely passed. Since you didn't make the visual overview, and there is some programming errors/bad practice, there is still room for improvements.
    It seems that you have understood the overall concept of interthreaded messaging.

    SvarSlet