ISU E8 - OS API

Exercise 1 Completing the Linux skeleton of the OO OS Api

In this exercise you will be tasked with completing the OSApi library. The following files are missing or have not been completed.

• inc/osapi/linux/Mutex.hpp - Missing
• linux/Mutex.cpp - Missing
• linux/Conditional.cpp - Already started
• linux/Utility.cpp - Missing
• linux/Thread.cpp - Already started
• linux/ThreadFunctor.cpp - Already started

To compile your revised version of the OSApi, use the following command:

make DEBUG=1 TARGET=host all

Mutex.hpp.

Mutex.cpp.

Conditional.cpp.

Utility.cpp.

Thread.cpp

ThreadFunctor.

Questions to answer:

• Inspecting the OSApi library, describe the chosen setup and how it works.
• All headers in the inc folder, so the makefile can choose the right OS for implementation.
• A thread function is a free C function, how is the connection made such that our desired run() method is called.
• Through the threadfunctor class
• In the windows implementation the so-called pimpl/cheshire cat idiom is used. Explain how it is used and what is achieved in this particular situation.
• It is a smart pointer. Used to hide private data.
• Why is the class Conditional a friend to class Mutex? What does it mean to be a friend?
• So Conditional can use mutex class without making mutex member data public.

Hint: See the interface for class Mutex as coded for the windows platform.

Exercise 2 On target

Verify that your OSApi library can compile for both Linux host and target. The same applies to your test applications.

Compile for host.

Compile for target

The makefile handles both types. You will get to different folders, host and target.

Questions to answer:

• Did you do need to change code for this to work, if so what?
• No. The only thing that the compiler needs to know is whether it is to host or target

Exercise 3 PCLS now the OS Api

At this point we have created the PCLS system and it works great with Message and Message queues

The next natural step is obviously to port your PCLS application such that it now is based on your newly created OS Api and at the same time use UML diagrams to depict the design.

Before you start coding you must make a class diagram as well as a sequence state/event diagram. Elaborate on your chosen design. Diagrams and design considerations must be part of your handing.

Again remember that the loop in the thread method run() must resemble the below code snippet:

Listing 3.1: Loop in thread function

1 void MyThread :: run ()

2 {

3 /* Whatever code you want */

4 while ( running_ )

5 {

6 unsigned long id;

7 osapi :: Message * msg = mq_ . receive (id);

8 handleMsg (msg , id);

9 delete msg ;

10 }

11 /* Whatever code you want */

12 }

What is important here is that the receive() function must be in this loop and NOT anywhere else!

Code:

Makefile:

These questions must be answered, either here or part of your design discussion above:

• Which changes did you make and why?
  
                   We use MsgQueue from OSApi and changed which class it is from(osapi::).
• Does this modification whereby you utilize the OSApi library improve your program or not.
  
                   No not really. We only get a higher level of abstraction. Now it is also easy to implement in another OS.