Hi, 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 enough. 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 ... Regards Felix > > - Michael >
