Got it! Makes sense. Just like the book you recommended states, sometimes the worst issue is not describing how a class is intended to be used w.r.t. thread safety and concurrency.
Thanks, - Ray On Tue, Jan 14, 2014 at 1:07 PM, BJ Hargrave <[email protected]> wrote: > > If you look at the tracker code now, if the tracked set of services > > was an immutable copy of the actual tracked services, the only > > access to the mutable collection would be from within > > "update" code which could be synchronized. During this same > > synchronized block the mutable collection could be copied to a > > volatile but immutable reference which is then used everywhere for > > access. This would give you the exact same safety while solving the > > concurrency issue. > > Unfortunately this won't work given the design of ServiceTracker which > allows subclassing. The getServices methods must call getServiceReferences > and then getService(ServiceReference) to allow the subclass to override > behavior. > > Even for getTracked, the method returns a writeable, sorted map, so it > must be a sorted copy of the internal map. If there was a > SortedCopyOnWriteMap class, this could be used for the internal map to make > the copy an O(1) operation but at the cost of making all map mutations more > expensive. So it may be a bad tradeoff for many. > > I think the best solution to your problem is what you have already done: > use a customizer/subclass to manage your own collection of the tracked > objects with the performance characteristics you need. > -- > > *BJ Hargrave* > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the *OSGi Alliance* <http://www.osgi.org/> > *[email protected]* <[email protected]> > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
