Goals:
Understand what an OS API is.
Being able to compile our own OO OS API library
Being able to use the OS API in our own solutions. (PCLS)
Exercise 1:Completing the Linux skeleton of the OO OS Api
Missing and incomplete files:
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
Complete them See the code at the end of this exercise.
Questions to answer:
Inspecting the OSApi library, describe the chosen setup and how it works.
Hint: Directory structure, de fine usage, handling platforms etc.
The OSApi contains an inc folder in which all the classes are defined. The inc folder holds header files which dependendly on which OS the current code is designed for will point to the specific version of a header file.
A thread function is a free C function, how is the connection made such that our desired
run() method is called.
By using the ThreadFuncter, which is kindof a middleman between initialization of our threads and our classes.
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.
We cant find it implemented in the OSApi we have however discovered that the pimpl/cheshire cat idiom is a private implementation technique which can only be used in statically compiled programming langaues. Its benefits are
Link to our source: http://c2.com/cgi/wiki?PimplIdiom
- Changing private member variables of a class does not require recompiling classes that depend on it, thus make times are faster, and the FragileBinaryInterfaceProblem is reduced.
- The header file does not need to #include classes that are used 'by value' in private member variables, thus compile times are faster.
- This is sorta like the way SmallTalk automatically handles classes... more pure encapsulation
Why is the class Conditional a friend to class Mutex? What does it mean to be a friend?
Hint: See the interface for class Mutex as coded for the windows platform.
A friend class can access private methoeds and data.
Mutex.hpp:
Mutex.cpp:
Conditional.cpp:
Utility.cpp:
Thread.cpp:
ThreadFunctor.cpp:
Exercise 2: On target
To compile to target you can simply change the target in the makefile from host to target. The correct compiler_setup file will automatically be used.
Questions to answer:
Did you do need to change code for this to work, if so what?
No code is needed to be changed.
Exercise 3: PCLS now the OS Api
UML-diagrams:
Class diagram:
Sequence diagram:
Design consideration:
Not much to discuss about the design. we are forced to use the OSApi and therefor that is what we do.
Design consideration:
Not much to discuss about the design. we are forced to use the OSApi and therefor that is what we do.
Questions to answer:
Which changes did you make and why?
We changed the thread, msgqeue and message classes to the OSApi version.
We redid the main function since Thread and pthread syntax is very different.
We had to change our entryguard, exitguard and carthread from functions to classes
Does this modi cation whereby you utilize the OSApi library improve your program
or not. Substantiate you answer with reasoning.
Since we only ever will use this program on linux systems this didn't improve that much. However the syntax and code is easier to read especially if you are used to OO programming. Mutexes are also hidden from the programmers.
Code: (our main.cpp contains our custom classes)
enum.h: handlers.h: Messages.h: main.cpp:
The focus in this exercise is to use OSApi. The ThreadFunctor enheritment is especially important to understand.
ReplyDelete1: The code for the OSApi seems to be in order. (good)
2: You have UML-diagram for ThreadFunctor which is considered especially important. (good)
3: There seems to be missing a few things here and there. Especially test / runs of the code / program. (bad)
When asked why conditional is a friend to mutex, you only answer what friend is, and not why conditional is a friend to mutex.
Just show the code which YOU have created. The code you haven't created isn't relevant to the reader, so just remove that from the wiki.
Diagrams:
The UML-diagram is VERY limited. It only informs about ThreadFunctor. We'd like to have information about message, msgQueues, message structs and enums.
When it comes to the sequence diagram, it's just entirely missing.
The design considerations seems unprofessional. Tell what the advantage is with this setup.
Which changes did you make and why?
You write that you have changed the msgqueue and msg classes for OSApi. We doubt that - if you have, please upload the changes.
We previously had a variabel which determines if the entry/exit door is open or closed. That you have removed, and now the close messages (ID_CAR_IN) does absolutely nothing.
Some cout's would be nice for the entry/exit doors, to check which messages are received.
When you get the entry_confirm, you enter the parking lot and sleep. After the sleep, the car should send a exit_request.
You do that in the main, but it should be in the handler. Only starting the thread should be in the main (the entry request).
You use a carID, but you don't print it out. It would be much easier to recognise which car enters, parks, and leaves if the ID is printed next to the message.
You don't show any runs of the program, so the it's difficult to see how the program runs.
You code is longer than the side of the wiki, make more lines (follow examples of the teacher).
You should NOT initialize new things in the middle of your code, this should have given you a warning, and is very poor programming. ex:
unsigned long idIn; and unsigned long idOut;
Still, it seems like you understand the important things in this exercise, so we barely let you pass.