On Sun, Dec 18, 2011 at 9:48 PM, Marcel Offermans <[email protected]> wrote: > 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.
I guess that makes a lot of sense. I'll ponder about it some more and in the meantime fix those locks :) grz Bram > Greetings, Marcel > > > _______________________________________________ > Amdatu-developers mailing list > [email protected] > http://lists.amdatu.org/mailman/listinfo/amdatu-developers _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
