Hello Bram, On Dec 18, 2011, at 20:39 PM, Bram de Kruijff wrote:
> lol! Guess I was asking for that... please rest assure that I am aware > of how Java works thanks you ;) Let me just reply to the relevant > part.. ...same here :) >> Because that would not solve the problem. The design choices are not OSGi's, >> they are Java's. We write Java, so the least we must do is learn the >> language. Concurrency is an important aspect of the language, and >> understanding the Java memory model is crucial. > > This is where I disagree. It is an OSGi design choices to use for > example a synchronous service lifecycle event mechanism. This single > choice, and I am not even saying it is bad per se, will probably be > responsible for 99 out of 100 deadlocks in an OSGi environment > (excluding the framework itself ;). Not just because people don't > understand the details of concurrency or are being lazy, but because > this design choice makes this aspect hard to handle for the > programmer. My feeling is that an asynchronous model would be more > forgiving, robust and scalable. I also think, looking at the specs, > that OSGi has been struggling with these choices. Some thing > synchronous, some thing asynchronous and sometimes you can choose. > Most explicit is maybe the spec requirements that ConfigurationAdmin > must invoke updated() asynchronous so that people can synchronize for > initialization(104.5.5). Think about that for a minute... requiring a > compendium service to behave as a async consumer while any arbitrary > consumer can invoke the producer sync at that point (because that how > java works). That teaches me that you simply cannot hold locks when invoking other services or the framework, because you're right, at that point anybody can invoke updated() on the ManagedService so I actually think that paragraph in the spec contains bad advice. > Now along that train of thought I was thinking we can't change OSGI, > but again this choice is in the dependency manager. You must have > though about sync/async behavior on the add and it would be trivial to > make it async. So that is where my whys came in... why did OSGi choose > this sync model, why did you choose it for dm.add as well and why > should I not consider making it async. I chose to use the same semantics that OSGi uses. Why? Because I don't believe that you can work with OSGi without understanding how to properly synchronize your code anyway so I did not even bother trying to asynchronously handle this aspect. The assumption would break down whenever you would call another service or anything framework (BundleContext) related anyway. Greetings, Marcel _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
