Posted March 05, 2017
I have a programming question to ask. It's not simple, and is not something I would expect a beginner to be able to answer. Here it is:
Suppose we have two (sort-of) threads, A and B. These aren't threads in the usual sense; instead, usually only A is executing. However, at unpredictable times, B will start executing; during this time, A will not execute until B returns. Furthermore, thread B *must* finish executing in a certain amount of time, or the entire program crashes. (In other words, consider B's task to be hard real time.) In order to do its task, B needs to use data produced by A; if B executes at a time when the data is unavailable, the entire program crashes (in other words, the data must always be available).
The problem is this: How can we get this working correctly, with B always being able to access the data produced by A, without creating race conditions or other concurrency issues?
Before anyone suggests it, something like a mutex will *not* work here. If A acquires the mutex then gets interrupted, B will block forever when trying to acquire the mutex (because A can't interrupt B), causing a deadlock, which is clearly not acceptable.
Note that what I am calling thread B could easily be a callback for an API (something like a signal handler), or it could be an interrupt service routine in kernel-level code.
Any ideas?
Suppose we have two (sort-of) threads, A and B. These aren't threads in the usual sense; instead, usually only A is executing. However, at unpredictable times, B will start executing; during this time, A will not execute until B returns. Furthermore, thread B *must* finish executing in a certain amount of time, or the entire program crashes. (In other words, consider B's task to be hard real time.) In order to do its task, B needs to use data produced by A; if B executes at a time when the data is unavailable, the entire program crashes (in other words, the data must always be available).
The problem is this: How can we get this working correctly, with B always being able to access the data produced by A, without creating race conditions or other concurrency issues?
Before anyone suggests it, something like a mutex will *not* work here. If A acquires the mutex then gets interrupted, B will block forever when trying to acquire the mutex (because A can't interrupt B), causing a deadlock, which is clearly not acceptable.
Note that what I am calling thread B could easily be a callback for an API (something like a signal handler), or it could be an interrupt service routine in kernel-level code.
Any ideas?