One of the main purposes of this module was to be able to understand and then use threads in an embedded system. The use of a raspberry pi gave the embedded system and the threads were implemented using python. There was a need to be able to use IPC (Inter-Process Communication) between the threads that were created to form communication between them.
A thread is the smallest sequence of programmable instructions that can be executed and that can be scheduled by the operating system's scheduler. A thread or threads are run inside of a process and a process can spawn and execute multiple threads, usually concurrently while sharing resources such as memory. The threads are switched so often that to a human observer it appears that these threads are running in parallel to each other. The operating system schedules access to the processor by allocating a time slice to a thread where it allowed to execute on the CPU before the thread is paused and another is allowed access. There are also multiple thread types but for the purpose of this module and for the sake of brevity in this blog post the type focused on will be user-space threads, this type of thread has its time scheduling implemented by a programmer who has to do the job of a scheduler manually.
Inter-Process Communication is a method used to share information between processes that may need access to the same resources, e.g. data needed by two or more processes. This is implemented in different ways depending on the operating system, methods used include semaphores, pipes and a shared message buffer. Strictly speaking the use of threads don't need this because the data on a thread is available to other threads that are running on the same process. They do however share the same problems when it comes to this sharing of data so a simple form of IPC to refer to how data is shared between threads is apt for this module.
A race condition is where processes or threads try to update the same data at the same time meaning one process may find that before it tries to update the data it has already been updated, embedded systems are usually used in safety critical areas and bugs that are caused by race conditions can have serious consequences and at the very least a lock on the data should be used to prevent the execution of code that changes the value of the data.
Using code with comments from sprint 1 to show how threads and a simple form of IPC to prevent race conditions occurring with locks as data was able to be been globally in the application. Once data was detected to have changed an event was set to let the system know that the thread for carrying out a movement operation could be unpaused and allowed to execute.
A servo was created to be a separate object to ensure that it was the correct servo being used, as well coming from a computer science which mainly focused on Object Oriented Programming as our method of designing programs. Each servo and the face detection was given its own thread, this was done by defining three functions:
- Pan Servo Thread
- Tilt Servo Thread
- Detection Thread
With each being assigned as the target of a new thread.
Above is example of one of the servo threads.
Full code is available at: https://github.com/ianmurphy1/lampbotics/tree/master/sprint1
and has been updated with comments to explain execution.