Experimental Physics and
Industrial Control System

Martin Konrad via Core-talk <[email protected]> · Tue, 18 Jun 2019 21:00:17 -0000

The problem I have with this is that

// ...
t1.joinWithTimeout(timeout);
// read something modified by t1

is a very common pattern. This is safe because join() acts as a barrier in terms of the memory model. If we proceed without ensuring the thread has shut down we need to ensure we never read/write anything that might be written/read by the thread because we can't be sure t1 has shut down. Otherwise we might have a data race (in other words: anything can happen).

Simple example:

void foo(atomic<bool>& terminate, int& shared) {
  while (!terminate)
    shared = ...;
}

{
  atomic<bool> terminate = false;
  int shared;
  thread t1(foo, terminate, shared);
  // ...
  terminate = true;
  t1.joinWithTimeout(timeout);
} // shared goes out of scope - but foo() might keep writing to it!

It's hard to use this correctly. Should you really implement a joinWithTimeout() I think it should come with a big fat warning in the documentation. I would certainly stay away from doing anything beyond calling "exit" if join times out since I'm pretty sure I wouldn't get it right.

P.S.: I like the idea of leveraging SIGALRM.
-- 
https://code.launchpad.net/~epics-core/epics-base/+git/Com/+merge/361379
Your team EPICS Core Developers is subscribed to branch epics-base:7.0.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System