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.
Denne kommentar er fjernet af forfatteren.
SvarSletKey points of this exercise is to:
SvarSletLearn 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