Real- time software /fall 00
     

    You must submit laboratory exercises 1-2 by the end of the study period one and labs 3 and 4a or 4b by the end of period II (every study period is 7 weeks). If you fail to submit a laboratory in time you get a new exercise to do. To be late has also an effect to your grade. A past experience shows, that students easily underestimate the time needed to test a program to work and start the work too late, you are advised to participate labs and not to leave work to the latest moment.

    Copying from other students is strictly forbidden. Identical works are rejected, also the original one. So, do not give your code to other students. You must set all rights to access to your directory of labs only to the owner (rwx------; chmod 700 lab_dir). Of course, you can help other students to learn and you are even encouraged to do so, the method can't be to give a ready made code. Two programmers have not  identical solutions to any problem "big enough". If the solution is clearly the same, different variable names or comments are not enough to prove the work to be different from an other solution otherwise similar.  Labs 3, 4a and 4b are checked by the teacher using Berkeley University moss- service and must be sent to the teacher as an e-mail all the source in one attachment file named by the student's login name and lab number. For example, if your login name is mattik and the lab is 4a the attachment file name is mattik4a.c
    Also, the exam is based on the skills developed with these exercises, so, there is no point to copy anything.

    Introductory exercises (1) and (2) are based on the material, which is also explained during lecture hours.

    An exercise is completed only if:

    • Demonstrated to be working to the teacher during laboratory hours (questions asked)
    • A paper copy with the documentation,  the program source, the name of the author and the date of completion submitted
    • Attachment file (3, 4a, 4b) is sent by e-mail (you must have your full name in the comment heading of your program.
    The attachment file contains only  .C  files put to one file (concatenated), you are not allowed to use any compressing or packing tool, because used moss- system packs files itself!

    First we take some basic disciplines as:

    • UNIX man- pages
    • compiling and linking a program using several separate source files
    • makefiles
    • libraries, header files
       
    (1) Compiling/header files/linking/separate modules
     
      The main program calls a subprogram which reads from the disk a text file to a buffer (the buffer address is a parameter to the subprogram). The main program calls an other subprogram, gets the buffer address as a parameter and calculates average of of all numbers and returns it to the main program, which prints it out. You can create the text file of numbers using simply a Linux text editor. (The source is directly portable to the lab 3.)

      The main program and both subprograms are written in a separate module (a different source file). Use also a separate header file.
       

           Libraries
     
      Read the manual and info page of the ar- command.
      Put the subprogram object files of the previous exercise to your own library and test again.
      Study also dynamic libraries ( ld -b ..., dld.sl).
    (2) Makefiles
     
      (a) Read the manual page of make- command and use the info command (info make).
      (b) Create a makefile for the exercise (1). You must have a makefile in which You use a library and other without a library. Test again.
       
      Every student takes the problem 3 and either the problem 4a or 4b. You should think about your available resources to complete the task in time (to the end of the period II). The number 4b is more difficult than 4a. Exercises expire at the end of period II. If the work is not done You can continue with new lab works.
      The grading is based basically as follows to the labs: To complete only lab 3 your grade is the exam result -1 , if you complete 3 and 4a, the grade is same as the exam result. If you complete 3 and 4b, your grade is the exam result +1 (if the grade is less than 5). This is a general rule, assessment rules of the Institute give some freedom based on other factors. So, if for example your exam result is 3 and you submit 3 and 4b, it is in some cases even possibility to the grade 5.
       
       
    (3) Modify and extend a simple example from course material (two-way-pipe.c)and your laboratory work 1

    Write and test the following program to get the basic idea of the so called inter process communication of multitasking systems:

    • We have two processes communicating with each other using named pipes or pipes.
    • The first (parent) process reads a file from disk (the name of file as command line argument) and sends the contents of it to other process, created as child.
    • The file contains
    • Invent some end of file indication for the child process.
    • Do not read the contents of the whole file in a memory buffer, you do not know the size of the file in advance.
    • The (child) calculation process calculates the average of all number values and sends back the average to the first process.
    • The first process displays the average.
    • Make a short documentation explaining your product.
    • Use makefile.

    (3-new) Phone number server- the expiration time of this exercise is the last lab hour of the next period (III) course.
     

    • We have two processes communicating with each other using pipes.
    • The first (parent) process reads names as user input and sends the name (one by one) using pipe to the child process.
    • The child process sends back phone number as an answer using an other pipe.
    • The parent process prints out the name and the phone number.
    • Names and phone number are in a disk file.
    • The number server seeks the phone number always from the file (the child process do not read the whole file in a buffer in the memory).
     
     


    Comments to next labs (4):
    Do not use the fork- system call. The processes are independently compiled programs communicating with each other using semaphores and shared memory. Access to same resource by known key- value. It is useful to use printouts for testing as: writer enters to waiting readers come out and sleep functions inside to slow down the process.
    Start test applications from a command file, plenty of readers and writer as:

    ./writer &
    ./reader &
    ./writer &
    ./writer &
    .....

    (4a- new) Load balancing buffer between processes -the expiration time of this exercise is the last lab hour of the next period (III) course.
     

    • We have two processes, both compiled as separate programs (different main programs).
    • The first process reads from a big disk file BUFFER_SIZE  float numbers a time in it's own data buffer area.
    • There is also a common buffer ( BUFFER_SIZE) between the processes.
    • This buffer is implemented as a shared memory segment.
    • The first process waits always the second process has read the last contents of the common buffer (semaphores used). See for example producer/consumer idea from lecture materials.
    • The second process reads numbers from the common buffer to it's own data area.
    • The second process waits if the first process has not got new data yet.
    • The second process calculates the average of the numbers and prints it out.
      • You must make a big test file (plenty of BUFFER_SIZE floats) with numbers easy to find is the calculation correct or not.

       
     

    (4a) File protection using semaphores
     

      Implement simple file protection using semaphores. We have a protected  file. Any number of readers can open it, but only one writer can exist a time. Test the implementation with a set of programs. You must implement a test case  with plenty of readers a the same time as well as the case of a process changing the file contents and readers becoming active during the update. You can use for example "sleep" function to slow down processes as wanted for test.
      The link to a  pseudo code solution to the problem.
       
       
    (4b) Semaphores and shared memory  (see the picture below)
     
      This is an example of producer/consumer problem explained in the lecture material.
      Write and test the the following system:
      • We have plenty of writer- and one reader process, which use a shared memory segment for IPC.
      • The writer sends the contents of a named ASCII text file (the name is as a command line argument to the sender) to the shared memory segment as packets (the shared memory has a limited size, the file has not). (For example: #define BUFFER_SIZE 1024).
      • We assume a technical solution as follows: When a new writer starts it marks a new buffer in the shared memory for it's usage. The shared memory is divided to constant defined number of buffers. If all buffers are in use, the new starting reader stops for waiting.
      • The writer processes wait on a semaphore if the reader has not yet read the data written earlier, also writer and reader can't access the memory segment when the other process is just accessing the data. Of course, also the reader waits, if it has no new data to be read from any of the writers.
      • Also if all buffers are used a writer waits, if all buffers are empty the reader waits.
      • The reader calculates the average of the numbers in every file and prints it out. (You must have some indication telling the transfer is ready.)
      • Make a short documentation explaining your product, use the standard documentation practices you have learnt so far.
      • Use makefile
      Initialize semaphores for clarity in a separate program started first.

      Semaphores and shared memories are destroyed by semctl and shmctl functions with IPCRM- flag.
      If not, you can destroy these by user command ipcrm (see manual page) and see existing ones with user command ipcs.
      If old zombie objects exist in the system it can cause problems in some cases..