> 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 [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
