1. Semaphore 김백규

2. What is Semaphore?  A semaphore is a protected variable.  method for restricting access to shared resources (e.g. storage) in a multiprogramming environment.multiprogramming  The value of the semaphore is initialized to the number of equivalent shared resources  binary semaphore : a single equivalent shared resource  counting semaphore : The general case semaphore

3. Semaphore operations

4. Implementing a semaphore  Incrementing the variable s must not be interrupted,  The P operation must not be interrupted after s is found to be nonzero.  This can be done by special instruction (if the architecture's instruction set supports it)instruction set  or by ignoring interrupts in order to prevent other processes from becoming active.interrupts

5. Creating a semaphore  We firstly need to know about a Queue structure in FreeRTOS.  Since a semaphore is implemented using Queue.  We will see the implementation of queue shortly  (Queue Management will be covered next time)  Queue operations (related to a semaphore)  QueueDefinition (Cover shortly)  xQueueCreate (Not cover here)  xQueueSend (Cover shortly)  xQueueReceive (Cover shortly)  xQueueReceiveFromISR (Not cover here)

6. Queue Definition These seem to related to semaphore

7. This will disable inturrpt. Call __asm{ cli } If xTicksToWait is specified, the task will wait during the time. If queue is full

8. Copy data to queue (This area can’t occur interrupt) All work is done, unlock the queue and resume all task.

9. This will disable inturrpt. Call __asm{ cli } If queue is empty If xTicksToWait is specified, the task will wait during the time.

10. Copy data from queue (This area can’t occur interrupt) All work is done, unlock the queue and resume all task.

11. Queue summary  Access to queue…  There are code for enable/disable interrupt  This provides queue to be accessed by only 1 task.  This concept may be used in implementing semaphore.

12. Semaphore implementation  Semaphore APIs only consist of MACRO  No need to implement full functions again.  Because we have a queue structure.  Semaphore macros  vSemaphoreCreateBinary  xSemaphoreTake  xSemaphoreGive  xSemaphoreGiveFromISR

13. Semaphore Macros

14. Example xSemaphoreHandle xSemaphore = NULL; void vATask( void * pvParameters ) { // Create the semaphore to guard a shared resource. vSemaphoreCreateBinary( xSemaphore ); if( xSemaphore != NULL ) { if( xSemaphoreGive( xSemaphore ) != pdTRUE ) { // We would expect this call to fail because we cannot give // a semaphore without first "taking" it! } // Obtain the semaphore - don't block if the semaphore is not // immediately available. if( xSemaphoreTake( xSemaphore, ( portTickType ) 0 ) ) { // We now have the semaphore and can access the shared resource. //... // We have finished accessing the shared resource so can free the // semaphore. if( xSemaphoreGive( xSemaphore ) != pdTRUE ) { // We would not expect this call to fail because we must have // obtained the semaphore to get here. }

15. History of semaphore  The canonical names P and V come from the initials of Dutch words.Dutch  the words for increase and decrease both begin with the letter V(verhoog, verlagen) in Dutch language.  V stands for verhoog, or "increase."  P stands for prolaag, short for probeer te verlagen, or "try-and-decrease".

16. A comparison between FreeRTOS and RTLinux in embedded real-time systems

17. Comparison on Size  Kernel Size  Few megabytes  RAM required  Over few megabytes  Kernel Size  About 4.4 kilobytes  RAM required  About 200 bytes RTLinux FreeRTOS

18. Platform support RTLinux  supports architectures like x86  much more complex (much due to the Linux kernel)  harder to port to new platforms. FreeRTOS  smaller microcontrollers  Support a greater number of platforms  portable code  all kernel code is contained in just three files

19. Features and Scalability RTLinux  Provide all the things that a normal Linux distribution can.  Down to ARM. Upwards to full grown "home computer systems". FreeRTOS  Provide only basic features.  only some basic scheduling  inter-process communication (IPC)  semaphores for synchronization  Hard to scale beyond the target of the platform.

20. Scheduler RTLinux  A simple insmod gives the possibility to change scheduler.  a basic highest priority first scheduler.  earliest deadline first FreeRTOS  a highest priority first scheduler.  same priority tasks is given "fair" process time by round robin.