0

I have two threads (in C) that execute the following instructions:

void Foo() {
   // function running in thread 1
   1| head = NULL;
   2| tail = NULL;
}

and 

void Bar() {
  // function running in thread 2
  1| mid = mid-next;
  2| tail = tail->next;
  3| head = head->next;
}

Now, my problem is related in the lock-free programming domain and it goes like this:

  • Thread 1 performs (1) and goes to sleep
  • Thread 2 performs (1) and (2) and goes to sleep
  • Thread 1 wakes up and notices (via a CAS instruction) that tail variable has changed and it rolls back its changes (the (1) instruction) and wants to help by continuing the Thread 2 work (the 3rd instruction from Bar method)

My question is: can we somehow continue the Thread 2 work from Thread 1? [e.g. by changing somehow the instruction pointer or by any other means] We can modify or persist all kind of thread state info.

Tamas Ionut
  • 4,240
  • 5
  • 36
  • 59
  • 2
    Neither C nor pthreads nor any other thread implementation I am aware of provides for the kind of behavior you describe, and rightly so. Multithreaded programming is already hard enough to do right without introducing craziness of the kind you propose. – John Bollinger Apr 03 '17 at 20:12
  • Perhaps yours is an X-Y problem, however. Why were you hoping to do what you described? – John Bollinger Apr 03 '17 at 20:13
  • Indeed it is :). But currently, I'm working on a side-project of automatic lock-free code generation from a single-threaded implementation. What I'm trying to do is exactly what I've described. – Tamas Ionut Apr 03 '17 at 20:14
  • The problem is how you automatically manage synchronization conflicts between threads in a lock-free data-structure: if a thread detects a conflict it will try to "help" the conflicting thread to complete its operation before retrying its own operation. – Tamas Ionut Apr 03 '17 at 20:17
  • I'm afraid you're out of luck. A thread performs work defined by its start function and the functions called directly or indirectly by that function, as influenced by any data it may read from memory or accessible devices. There is no defined way for it to jump to unrelated code, or, having done so, to jump back. – John Bollinger Apr 03 '17 at 20:18
  • 1
    If you want two threads to cooperate on a task, whether for manipulating a lock-free data structure or for any other purpose, then their code must be written specifically to do so. – John Bollinger Apr 03 '17 at 20:20
  • What about setjmp/longjmp? Can't these provide a workaround with careful use about the stack? – Tamas Ionut Apr 03 '17 at 20:23
  • `setjmp()` / `longjmp()` are unlikely to serve your purpose. A full discussion would be much too long for a comment, but among other details, they cannot provide for a return jump. – John Bollinger Apr 03 '17 at 20:28
  • What you are trying to do is, in general, not feasible since each thread would have no idea what they other threads would be doing, so resolving the potential state conflicts is hard to say the least. The interrupted thread could be right in the middle of a non-idempotent operation like writing output: in such a case, the other thread cannot tell if the output was written or not, so cannot ensure it gets written exactly once. In the spirit of what you are trying to achieve, we have successfully done it by ensuring threads have well defined state checkpoints where they can be stopped/resumed. – ScottK Apr 03 '17 at 20:33

0 Answers0