The future of concurrent programming

[Regan Heath]

BCS Wrote:
> Regan Heath wrote:
> > That just leaves the deadlock you get when you say:
> > 
> > synchronize(a) { synchronize(b) { .. } }
> > 
> > and in another thread:
> > 
> > synchronize(b) { synchronize(a) { .. } }
> > 
> 
> what D need is a:
> 
> synchronize(a, b) // gets lock on a and b but not until it can get both
> 
> Now what about where the lock are in different functions.... :b

Exactly.  In my reply to Sean I mentioned a possible solution which is perhaps more robust and flexible:

<quote me>
In the case I mention above you can at least solve it by giving each mutex an id, or priority.  Upon aquisition you ensure that no other mutex of lower priority is currently held, if it is you release both and re-aquire in the correct order (high to low or low to high whichever you decide, all that matters is that there is an order defined and adhered to in all cases).
</quote>

In other words you solve it by defining an order of aquisition in the implementation itself, so the programmer cannot make that mistake.

Regan Heath