Linked by Hadrien Grasland on Fri 27th May 2011 11:34 UTC
General Development After having an interesting discussion with Brendan on the topic of deadlocks in threaded and asynchronous event handling systems (see the comments on this blog post), I just had something to ask to the developers on OSnews: could you live without blocking API calls? Could you work with APIs where lengthy tasks like writing to a file, sending a signal, doing network I/O, etc is done in a nonblocking fashion, with only callbacks as a mechanism to return results and notify your software when an operation is done?
Thread beginning with comment 474862
To view parent comment, click here.
To read all comments associated with this story, please click here.
Alfman
Member since:
2011-01-28

JAlexoid,

"If it's on another thread then that is not in the same call stack, is it?"

I think the problem was brought up in terms of one stack, but the situation could happen with more.


"Otherwise that problem has been successfully mitigated using reentrant mutexes, such as used in Java."

I had never heard of this terminology.
A "reentrant mutex" allows a single thread to acquire a mutex multiple times from the same thread without blocking.

However I don't think it solves the problem.
Presumably mutex a is being used to protect a structure which is in an incomplete transitionary state (which would make it detrimental for a 2nd instance of A to continue without blocking).

On the other hand, if we know that A is reentrant and it is safe to let other drivers call A again, then the solution would be to just release the mutex before calling the other drivers.


"But the problem is really bad where you use sub-threads that access a shared resource."


For illustration...

Thread 1:
Driver A (acquire reentrant mutex a)
- Driver B
-- Spawn thread 2
-- Misc work
-- Join thread 2

Thread 2:
Driver B
- Driver A (deadlock on reentrant mutex a)
- exit thread


This scenario isn't all that unreasonable. I'm not certain where a reentrant mutex would be beneficial? Certainly it could be emulated using thread local storage.

Reply Parent Score: 2

JAlexoid Member since:
2009-05-19

Well you then know not much about how Java and C# synchronisation mechanisms work. If you're into Java I suggest watching some of Cliff Click's tech talks on concurrency and memory model.

Reentrant mutex or lock works by allowing the same thread to acquire it more than one time. Also requires it to be released the number of times it was acquired. It essentially has the owning thread + counter.

Reply Parent Score: 2

Alfman Member since:
2011-01-28

JAlexoid,

"Well you then know not much about how Java and C# synchronisation mechanisms work. If you're into Java I suggest watching some of Cliff Click's tech talks on concurrency and memory model."

Well that's just not fair, your trying to make fun of me and I'm trying to have a serious discussion... I won't go to your level.

"Reentrant mutex or lock works by allowing the same thread to acquire it more than one time. Also requires it to be released the number of times it was acquired. It essentially has the owning thread + counter."

You're echoing what I had said... in any case, it wasn't applicable to the problem being discussed.

Reply Parent Score: 2