4

What changes need to be made to a language/runtime if one wants to implement fully asynchronous exceptions (thrown from one thread to another, capable of interrupting pure computation without the need for polling)? What issues and challenges need to be addressed and how? What would be the difference in implementation between compiled, JIT-ed and interpreted languages?

  • What would be the semantics of such exceptions? What would the thread throwing the exception do? Wait for an answer from the receiver of the exception? How would the receiver thread react? Interrupt any work it was doing in order to handle the exception? Or would it be supposed to be an idle thread whose only purpose is handle exceptions? What would be the use / advantage of asynchronous exceptions? – Giorgio Nov 20 '16 at 19:27
  • @Giorgio precisely, .... I've tried to ask the broader questions, but I've been shot down, maybe I just don't know how to ask right,... anyhoo ... the way I see it, the throwing thread throws and forgets, the receiving thread behaves as if a rethrow appeared at the point of interruption, some outer function would catch it. It can be used e.g. to interrupt a long running calculation. .... having an idle thread for this is the same as a inter-thread message passing. – Martin Nov 20 '16 at 19:44
2

Well, that's basically what interrupts are at the OS/interprocess level.

For a multithreaded environment, your main challenge will be making it work with mutex mechanisms used to prevent race conditions in shared memory.

My intuition is that this will prove to be impossible.

It could work with environments that don't have shared memory between threads, like Erlang.

| improve this answer | |
  • 1
    Or with other higher-level concurrency mechanisms like Futures/Promises. Surely this problem has already been solved at the OS/Interprocess level. – Robert Harvey Nov 20 '16 at 19:48
  • @RobertHarvey can the Future/Promise model be interrupted without polling? "stop calculating NOW" instead of "while(!should_stop){do_a_little();}" – Martin Nov 20 '16 at 20:03
  • @RobertHarvey: No, as far as I can tell, at the interprocess level the "solution" is to either just disable interrupts while executing critical sections, or to make the interrupt handler explicitly handle any data corruption that might have happened because it was called. – Michael Borgwardt Nov 20 '16 at 21:26
  • @MichaelBorgwardt what kinds of race conditions do you expect to encounter in addition to the ones already occurring in MT programs? I mean, what new problems are being added. – Martin Nov 21 '16 at 8:59
  • @Martin: Interrupts work without polling at the hardware level, but the price is that your code is stopped in the middle of whatever it was doing, so e.g. it could leave some data structure half-intialized and thus in an inconsistent state. And you'd have the thread holding locks intended to prevent other threads from seeing that inconsistent state. If you just release the locks, you have corrupted data, if you keep them you have a deadlock. – Michael Borgwardt Nov 21 '16 at 11:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.