felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: More DS concurrency problems
Date Wed, 06 Jun 2012 10:17:04 GMT

Am 05.06.2012 um 16:57 schrieb Michael Fraenkel:

> On 6/5/12 8:11 AM, Felix Meschberger wrote:
>> Hi,
>> I fear we are getting on the "ever-and-ever-more-complex" track ...
>> I understand the concurrency issues (how the come into live) but I would love if
we could solve them with simple code without inventing more and more locking and and signaling
etc. behaviour. This really was the "beauty of some sorts" of the previous lock-less approach.
>> I think under certain circumstances there will always be a situation where one event
(service or configuration) is happening while at the same time another event is being handled.
In some situations -- e.g. a required dependency being unregistered while requiring the component
is being activated -- the ongoing task should probably be aborted and reverted. Which in turn
may be simpler (before service registration) or harder (during service registration).
>> This can maybe be solved by using checkpoints: Long running tasks (mostly activation)
after each step check the checkpoint while intermittent events (service, configuration) may
set the checkpoint and optionally wait for the checkpoint to be confirmed by the long-running
task (eventually timing out to prevent deadlocks). Such a thing would be "easier" to implement
with an Activating state where just the Activating.deactivate method might be called which
would handle the checkpoint thing.
>> Do I sound getting complicated ? ;-)
>> Regards
>> Felix
> It all comes down to a question of guarantees and what you are willing 
> to live with.
> The most basic locking could be accomplished just when touch the 
> "state".  You hold the lock if you are going to change the state.
> You use a lock to retrieve the current state.  Anything after retrieving 
> is a best effort.  You make the assumption that you exist in this state 
> until a failure occurs.  This would provide guarantees across switching 
> state and some minimal deadlock prevention.
> The ReadWrite lock idea was to just separate the two concepts above. 
> Transitioning requires the Write lock and the Read lock is used if you 
> are performing some activity within the given state.  It accomplishes 
> the same goal just with stronger guarantees.

Ok. The question is: Who is acquiring the locks.

For simple operations like "bind, "unbind", "activate", "deactivate" this is ok and atomic

The problem we have is with "reactivation" which currently is down by calling the sequence
of deactivate and then activate which both indepentently acquire the lock. Maybe we should
introduce new "reactivate" method (we had it once some time ago) which acquires the lock,
calls deactivate then activate and then unlocks again.

And keep in mind: We still want to be Java 1.4 compliant ...


> - Michael

View raw message