Data integrity - mutexes

The scheduler runs in a thread of its own using the pthreads library. This means that it has access to all functions and data in olsrd, while still maintaining its own program flow. This again leads to the problem of multiple resources accessing the same data ``simultaneously'', known as a race condition. This could occur in olsrd in a situation where a packet generation process initiated by the scheduler, builds a packet based on the link-set. At the same time the link-sensing functionality called by the packet-parser running in a separate thread, is writing to the link-set. This type of situations must be avoided, and to do this the common practice is to utilize some sort of locking of code regions. This means that a thread is only allowed to access certain parts of a program, called a critical section, if it can take hold of a certain resource. This resource is the lock. While one thread holds the lock no other threads can take it. This is also referred to as mutual exclusion. Therefore the lock resource is often referred to as a mutex.

Olsrd utilizes the pthread mutex API to make sure the functions called by the scheduler and the packet-parser never runs simultaneously. The socket parser has to acquire the lock to be able to call the appropriate packet-parser function when receiving traffic. The scheduler has to acquire the lock to be able to execute any of the registered functions. The design is illustrated in figure 6.9.

Figure: The parts of the code protected by the mutex.