Description
An operative system is a software layer that is executed on top of hardware to offer some services. Increasingly, the functionalities of an operative system include more tasks and cover more services. The objective of the subject is to see an operative system in all of its parts, and in this way, provide the student with knowledge from one of nowadays most important components of computer systems. In this subject, deeper fundamental concepts of operative systems will be covered, leaving for other subjects the details and specifications of other modules. In a practical point of view, practices with diverse functionalities will be performed, including policies or techniques of an operative system. Moreover, multiple examples are introduced which will help the student to delve into all those aspects that have been dealt from the theoretical point of view and allow them to see their application.
Type Subject
Tercer - Obligatoria
Semester
First
Course
2
Credits
6.00

Titular Professors

Director of Educational Innovation
Previous Knowledge
Objectives

The Learning Outcomes of this subject are:
RA.1 Basic concepts of operating systems.
RA.2 Knowledge from the different components or subsystems of an operative system and the techniques or strategies that are applied to each one of them.
RA.3 Identification, formulation and resolution of problems with concurrent processes that require an integrated system with common shared data.
RA.4 Design and implementation of multi-process applications that have shared information

Contents

CONCEPTUAL CONTENTS
Chapter 1. Introduction to Operating Systems
Chapter 2. Operating System core
Chapter 3. Scheduling
Chapter 4. Communication, Synchronization and Mutual exclusion mechanisms

PRACTICAL CONTENTS
Chapter 5. System calls

Methodology

Sessió 09 Global
The subject has a 2 lecture per week structure:
• The first one covers the necessary tools for the development of the laboratory sessions and examples and problems are resolved with the utilization of them. Also, the contents of the subject are developed through master classes and problems.
• The second session consist on a laboratory session where the student must solve a problem designing and implementing a program using the tools explained at the first sessions. This program must be submitted at the end of the session.
PRACTICAL LABORATORY SESSIONS
The practical sessions are lecture sessions that are part of the subject and that have a weekly periodicity during the hole development of the subject. The goal is to give support and favor the progressive learning, necessary and essential in order to successfully overcome the practical application of the contents of the subject as well as the practice to design and implement.
The operation of this sessions is described below:
• With a week in advance the contents of a programming tool in C will be taught to the students who will need them for the weekly practical session.
• If the necessary knowledge is a reminder from previous years or easy to assimilate, all associated bibliography and material will be provided to prepare them.
• If the necessary knowledge is new to the students these will be explained in the previous lecture sessions and, moreover, an associated bibliography and material will be provided to prepare them.
• Next, a practical exercise will be provided to the student who will have to solve and deposit in an eStudy task within the established term (usually at the end of the practical session)
• Once the task is closed, a correct solution of the exercise will be published so the student can do a formative self-evaluation.
• The monitors of the subject will qualify the given exercises and publish the notes to the eStudy.
Stablished sessions in detail:
Session 00 Reminder + File Descriptors
Session 01 File Descriptors + Signals
Session 02 Forks
Session 03 Threads
Session 04 Sockets I
Session 05 Sockets II
Session 06 Pipes
Session 07 Semaphores I
Session 08 Semaphores II
Session 09 Global

Evaluation

EVALUATION SYSTEM
 The subject lasts one semester and it consists in two different parts: the conceptual part and the practical one. The evaluation of the practical and the conceptual part will be independent. In order to pass the subject, you must pass both parts separately.
 The final grade of the subject will be computed as following:
Final_Grade = 40% · Concepts + 60% · Practice
 The concepts will be evaluated from the following marks: exams marks (Ex_Mark) and the laboratory exercises marks (Lab_Mark), computed as following:
Concepts = 60% · Ex_Mark + 40% · Lab_Mark
 The previous calculus will only be applied if the exams mark is equal or higher than 3.5 (Ex_Mark >= 3.5).
 Moreover, the exams mark (Ex_Mark) will be calculated from the marks of the midterm exam (Midterm_Ex) and the final exam mark (Final_Ex), computed as following:
Ex_Mark = 80% · Final_Ex + 20% · Midterm_Ex
 If the Midterm exam mark is equal or higher than 6 (Midterm_Ex >= 6), the concepts of this exam will remain passed for the final exam (ordinary or extraordinary call) and the student will be exempt of doing this part of the exam.
 Apart from the final exam in the ordinary call, there will be the possibility to do a second-chance exam (extraordinary call) for those people who did not pass the previous exam.
 As the laboratory mark (Lab_Mark) has a Continued Evaluation function, this will only be counted as Concepts for the ordinary call. For the extraordinary call, Concepts = Ex_Mark.
 When it comes to the practice evaluation, it is explained below with the practice normative.
 Referring to the functioning of the laboratory sessions, all the students who deliver the 85% of the laboratory sessions will be guaranteed with a 5 in this part, independently of their mark. A session will be considered delivered if the exercise is minimally complete and it reflects some effort. Otherwise, the session will be evaluated as Non Presented (NP).
 Finally, the students will have the option to not do the final exam. In order to achieve this, four factors will be studied: (1) the practice must be delivered and passed before the ordinary call; (2) the attendance to the laboratory sessions and the marks obtained; (3) the Midterm mark and (4) the attendance and participation to the lessons during the curse.
Final_Grade = (65%*Practice + 25%* Lab_Marl + 10%* Midterm_Ex) * Participation
According to the Cheating Normative the categorization of the evaluation activities is the following:
• Practice: Highly significative.
• Midterm exam: Highly significative.
• Final exam: Highly significative.
• Laboratory sessions: Moderately significative.
This means that if a student copies in a laboratory session, automatically the Laboratory Mark (which is the 40% of the Concepts mark) will be 0.
NORMATIVE OF PRACTICES
The practice of the Operative Systems subject (OS) is very important. The reasons are diverse: the practical application of the theoretical concepts explained during lectures, the ability to design and implement programs with a certain volume of number of lines and functionalities that the student must demonstrate, the applied complementation of certain conceptual concepts of operative systems, etc. For this reason, the practice of the subject demands an important effort on the student dedication and also they have a high control level and tracking from the monitors and professors implied.
Next, the basic norms that must be respected regarding the development of the practice for the present academic year are described:
1. The practice of the subject can be developed individually or in pairs with another person enrolled in the course.
2. Regardless of whether the practice is implemented individually or in pairs, this option must be notified to the monitors and professors of the subject with enough time so that there is a record and a group number for the practice can be assigned along with other technical resources, if necessary.
3. It is mandatory to have a group number assigned to be able to deliver the practice and its checkpoints.
4. The practice group must be identified within 3 weeks before any of the practice deliveries. If not, the presentation of the practice in that call for submission will not be accepted.
5. If during the academic year there’re any changes or modification concerning group formations, this must be notified to the monitors and professors of the subject, so this information remains up to date. In the same way, no changes will be allowed passed 3 weeks before a call for submission (the separations will be allowed but not new formation of groups).
6. The programming language used in the OS practices will be C language. Any practice delivered in any other language or variant will not be admitted (C++, Java, etc.).
7. For the practice there will be a maximum of 4 deadlines. The later the practice is delivered, the further penalty to the maximum qualification to obtain will be. This will be detailed in the practice statement.
8. For every call of submission, the student has a maximum of 3 possibilities to deliver the practice. This must be consequently time spaced so the monitors can give feedback.
9. La qualification of the practice can be also affected from different checkpoints that it can have. All the planification and final delivery dates including checkpoints will be detailed in the statement.
10. For the practice to be accepted and have the option to be qualified it must satisfy 5 requirements:
a. It must be delivered to the corresponding practice task (with the corresponding format) before the corresponding deadline.
b. It must be properly structured and have a corresponding internal documentation.
c. It must have a correct report.
d. It must work properly.
e. The group that presents the practice must pass an individual interview with the monitors where they must demonstrate a deep knowledge of the whole practice.
11. If any student doesn’t prove a deep knowledge of the practice, it will suppose the non-acceptance of the practice for that student that will have to implement it, from that moment on, individually and not being able to take advantage of any resource or code of the previous practice.
12. If a copy of practices is detected, the penalties of the school regulations will be applied, corresponding to fraudulent actions classified as serious or very serious.
NORMATIVE FOR REPEATING STUDENTS
The students who are repeating the subject have recourse to the following normative when it comes to evaluation:
• The qualifications of both parts (concepts and practice) can be saved separately between academical courses.
• The practice mark will be saved between academical courses if it is passed and the learning goals have not changed. If the student wants to validate the practice with the previous course mark, he/she will have to notify it to the subject responsible before October 15. If this is not notified, it will be considered that the student does not want to validate the previous practice.
• If a repeating student has the practice passed, he will be exempt to do the laboratory sessions. Consequently, this mark will not affect at the Concepts evaluation.
• When it comes to any other situation, the student will have to respect the current course normative. For any other reason, it is recommended to have a personal interview with the subject responsible (always before the start of the course).

Evaluation Criteria
Basic Bibliography

AGANS D.J. (2002). Debugging. The 9 indispensable rules for finding even the most elusive software and hardware problems, Amacom, 2002, ISBN 0-8144-7457-8.
CANALETA, X. (2020). “Exercicis i problemes d’examen de sistemes operatius”, Publicacions La Salle, September 2020.
HARBISON S.P. & STEELE G.L. (2002). C - A Reference Manual, Prentice Hall, 5th edition, 2002.
PETERSON, J.L. & SILBERSCHATZ A. (1989). Sistemas Operativos, Editorial Reverté, ISBN: 84-291-2693-7
SALVADOR, J. (2014) “Programació en C per a sistemes UNIX”, Publicacions La Salle, September 2014.
SALVADOR, J. (2011). Introducció al llenguatge de programació C, Publicacions La Salle, July 2011.
SILBERSCHATZ A., GALVIN P. & GAGNE, G. (2002). Sistemas Operativos, Editorial Limusa, ISBN: 968-18-6168-X
STALLINGS, W. (2005). Sistemas Operativos, 5th Edition, Pearson Prentice Hall, ISBN: 84-205-4462-0
STEVENS, R., FENNER, B. & RUDOFF, A.M. (2004). UNIX Network Programming, Volume 1: "The sockets Networking API", Addison-Wesley Professional, 2004, 3rd edition, ISBN 0-13-141155-1.
STEVENS, R. & RAGO S.A. (2008). Advanced Programming in the UNIX Environment, Addison-Wesley Professional, 2008, 2nd edition.
TANENBAUM A.S. (2009). Sistemas Operativos Modernos, 3rd Edition, Pearson Prentice Hall, Pearson Educación, ISBN: 978-607-442-046-3.

Additional Material