Politecnico di Milano FACOLTÀ DI INGEGNERIA DELL INFORMAZIONE. Real-Time Operating Systems A.A Exam date: 11 Sep 2014

Transcription

1 Politecnico di Milano FACOLTÀ DI INGEGNERIA DELL INFORMAZIONE Real-Time Operating Systems A.A Exam date: 11 Sep 2014 Prof. William FORNACIARI Surname (readable)... Matr... Name (readable)... Signature... Q1 Q2 Q3 TOT NOTES It is forbidden to refer to texts or notes of any kind as well as interact with their neighbors. Anyone found in possession of documents relating to the course, although not directly relevant to the subject of the examination will cancel the test. It is not allowed to leave during the first half hour, the task must still be returned, even if it is withdrawn. The presence of the writing (not delivered) implies the renunciation of any previous ratings. Question Q1 Explain what a Makefile is and what it does, detailing its syntax. Extra: Write a Makefile that compiles a program composed of five source files: main.c net.c net.h user.c user.h into an executable named prog Question Q2 The software for a bank holds the data for their clients in the following data structure struct Client char name[128]; char surname[128]; unsigned int id; unsigned int balance; pthread_mutex_t mutex; ; You are required to write a function struct Client *newclient(const char *name, const char *surname, unsigned int balance); that returns the data structure for a new client of the bank, generating an always different user id (for example, incremental). The user account is created with an initial amount of money, given by the function parameter balance. You are then required to write a function bool transfermoney(struct Client *destination, struct Client *source, int amount); to transfer money between two clients. The bank system is heavily multithreaded, so this function must make sure no race condition happen while the money is being transferred between the two clients. 1/11

2 Solution: Although not explicitly written, the function must allocate the struct on the heap with malloc(), since a pointer to it needs to be returned. Writing buffer overflow-safe code is not required for the exercize to be evaluated positively, but would definitely be required in a real bank system. Mutexes inside data structures can only be initialized with the pthread_mutex_init() function and not with PTHREAD_MUTEX_INITIALIZER. Also note that there is no need to lock the mutex during this function. This is because until the function returns no other part of the program can get a pointer to our newly created client, so no other thread can access it and generate race conditions. struct Client *newclient(const char *name, const char *surname, unsigned int balance) struct Client *result=(struct Client *)malloc(sizeof(struct Client)); //Handle out-of-memory situations if(result==null) return NULL; //We don't want to leave buffer overflows in a bank system, right? const int maxlen=128; strncpy(result->name,name,maxlen); result->name[maxlen-1]='\0'; strncpy(result->surname,surname,maxlen); result->surname[maxlen-1]='\0'; //Handle user ID static pthread_mutex_t m=pthread_mutex_initializer; static int id=0; pthread_mutex_lock(&m); result->id=id++; pthread_mutex_unlock(&m); result->balance=balance; pthread_mutex_init(&result->mutex,null); return result; A way to implement the function is to lock both mutexes before accessing the data structures. However, if two transactions with reversed source and destination happen almost simultaneously, this could generate a deadlock. bool transfermoney(struct Client *destination, struct Client *source, int amount) pthread_mutex_lock(&destination->mutex); pthread_mutex_lock(&source->mutex); bool result; if(source->balance >= amount) source->balance-=amount; destination->balance+=amount; result=true; else result=false; pthread_mutex_unlock(&source->mutex); pthread_mutex_unlock(&destination->mutex); return result; 2/11

3 A possible solution is to lock each mutex individually, although the transaction is not fully atomic, i.e. some other thread can see the intermediate state where money have been subtracted by one account but not added to the other one. bool transfermoney(struct Client *destination, struct Client *source, int amount) bool result; pthread_mutex_lock(&source->mutex); if(source->balance >= amount) source->balance-=amount; result=true; else result=false; pthread_mutex_unlock(&source->mutex); if(result==false) return false; pthread_mutex_lock(&destination->mutex); destination->balance+=amount; pthread_mutex_unlock(&destination->mutex); return true; Another solution is to use a deadlock avoidance algorithm to always lock the mutexes in the same order bool transfermoney(struct Client *destination, struct Client *source, int amount) if(source<destination) //Pointer comparison pthread_mutex_lock(&source->mutex); pthread_mutex_lock(&destination->mutex); else pthread_mutex_lock(&destination->mutex); pthread_mutex_lock(&source->mutex); bool result; if(source->balance >= amount) source->balance-=amount; destination->balance+=amount; result=true; else result=false; if(source<destination) //Pointer comparison pthread_mutex_unlock(&destination->mutex); pthread_mutex_unlock(&source->mutex); else pthread_mutex_unlock(&source->mutex); pthread_mutex_unlock(&destination->mutex); return result; 3/11

4 Question Q3 Consider the following fragment of an hypothetical datasheet which describes some registers of a GPIO peripheral. Also consider that a red LED is connected between GPIO 4 and ground, a green LED is connected between GPIO 7 and ground (both with their current limiting resistor), and a button is connected between the microcontroller power supply and GPIO 1 (with a pull-down resistor). Bit access modes: r = read-only bit, software writes are ignored rw = software reading and writing is allowed GPIO_DR: Address: 0xffff0000, Initial value upon reset: 0xffff This register allows to configure the individual direction of each of the 16 GPIO. If a bit is set to 0 the corresponding pin is an output, if it is set to 1 it becomes an input rw rw rw rw rw rw rw rw rw rw rw rw rw rw rw rw GPIO_AR: Address: 0xffff0004, Initial value upon reset: 0x0000 Writing an 1 to a bit in this register configures the corresponding GPIO as an analog input, connected to the internal ADC, writing a 0 leaves the pin as an ordinary GPIO. This register overrides the input/output selection of GPIO_DR rw rw rw rw rw rw rw rw rw rw rw rw rw rw rw rw GPIO_IR: Address: 0xffff0008, Initial value upon reset: undefined This register allows to read the state of GPIOs configured as (digital) inputs. The bits that correspond to pins configured as output or analog input read as r r r r r r r r r r r r r r r r GPIO_OR: Address: 0xffff000c, Initial value upon reset: 0x0000 This register allows to set a GPIO configured as output to either 0 or 1 logic level rw rw rw rw rw rw rw rw rw rw rw rw rw rw rw rw You are required to: 1. write a data structure (namely GPIO_Struct) and a macro (namely GPIO) which could be used to access these peripheral registers, by a C/C++ coded program, using a syntax similar to GPIO->OR; 2. write a function void GPIO_Init(); to initialize the GPIO peripheral taking into account the hardware connected to it. Unused pins must be configured as output, low logic level. 3. Write four functions void red_led_on(); void red_led_off(); void green_led_on(); void green_led_off(); to control the two LEDs on the board. 4. Write a function int button(); that returns 1 if the button is pressed. 4/11

5 Solution: struct GPIO_Struct volatile unsigned short DR; 0xffff0000 unsigned short padding1; volatile unsigned short AR; 0xffff0004 unsigned short padding2; volatile unsigned short IR; 0xffff0008 unsigned short padding3; volatile unsigned short OR; 0xffff000c ; #define GPIO ((struct GPIO_Struct*)0xffff0000) void GPIO_Init() GPIO->DR=(1<<1); //Only button is an input GPIO->AR=0; GPIO->OR=0; //Start with leds turned OFF void red_led_on() GPIO->OR = (1<<4); void red_led_off() GPIO->OR &= ~(1<<4); void green_led_on() GPIO->OR = (1<<7); void green_led_off() GPIO->OR &= ~(1<<7); int button() return GPIO->IR & (1<<1)? 1 : 0; 5/11

6 Politecnico di Milano FACOLTÀ DI INGEGNERIA DELL INFORMAZIONE Real-Time Operating Systems A.A Prof. William FORNACIARI Surname (readable)... Matr... Name (readable)... Signature... Answer to Q1 6/11

7 7/11

8 Answer to Q2 8/11

9 9/11

10 Answer to Q3 10/11

11 11/11