Re: [platform-core-dev] Concerns regarding deadlock avoidance

["John Arthorne" <John_Arthorne@xxxxxxxxxx>]

That is how it currently works, but
it is an experimental approach.  It would require clients to ensure
integrity of their data structures before attempting to acquire other locks.
 I.e., if you have acquired a lock to protect your data structures,
but then you want to call out to other client code that might acquire locks,
you would have to be prepared to lose your original lock "while you're
waiting".  It still ensures that no two threads are accessing
a region simultaneously.

We have been debating whether this is
a reasonable thing for clients to accept.  It seems likely that people
will not read the fine print, and just assume that the region between acquire
and release is essentially atomic.  The problem is that there's no
other way to avoid deadlock in a system like Eclipse where components often
don't know about each other.  The only way to be ensure your component
doesn't cause deadlock is to never call other component API while your
own lock is held.  It can be argued that the deadlock avoidance strategy
I describe is essentially an enforcement of that principle.  If you
never call other components when your lock is held, then there is no danger
of having it taken away.  I think it would be a good idea for us to
at least log something to the platform log when this happens, so there
is some record of what happened.

The only other alternative is for us
to use the centralized lock mechanism for deadlock detection only, and
then break the deadlock by arbitrarily choosing one of the threads in the
cycle and throwing an exception on its blocked acquire call.  I don't
really like this alternative either, since it can just as easily leave
your data structures in a corrupt or half-written state, unless you take
the precaution of doing all the proper cleanup in a finally block.  I
am keen to hear other people's thoughts on this.

John.

Boris Pruessmann <boris@xxxxxxxxxxxxxx> Sent by: platform-core-dev-admin@xxxxxxxxxxx 07/20/2003 06:20 AM Please respond to platform-core-dev

To:        platform-core-dev@xxxxxxxxxxx         cc:                 Subject:        [platform-core-dev] Concerns regarding deadlock avoidance

Hi everyone!

Taking a look at how the avoidance of deadlocks is implemented, I was 
wondering whether this kind of implementation really works out. If I 
understand the code correctly, ordering of locks if forced by (eventually)
releasing locks that a thread already holds. Although this assures that
there are no deadlocks, I think this is likely to break the integrity of
data structures that were protected by the released lock. A contending
thread might gain access to data that e.g. is in an incomplete state.

If for example the lock is used to protect a cache, it might happen that
a 
thread that is modifying the cache in transactional way is loosing the
lock, 
thus allowing another thread to read dirty data. 

Is this really intended or am I just missing an obvious piece information?

Cheers,
Boris