DS & Concurrency

[Peter Kriens]

I’ve created an app note about concurrency and DS with lots and lots of examples. There is also a workspace with copyable examples of DS components that do wide ranging concurrent things.

http://enroute.osgi.org/appnotes/concurrency.html

Feedback appreciated …

Kind regards,

Peter Kriens

[Bryan Hunt]

Hi Peter,

Overall a great article!  Thanks for putting this together.

The section on Atomically Closing was confusing.  I understand what you are doing in the close(), but don’t see how that has anything to do with unbind and deactivate.

In the section Guarantees from DS -> Ordering, The wording of 3. Activate "Only if all methods are called is the activate method calls” is a bit confusing.

In the section Static References, it would be helpful to explain why you don’t need to use volatile for reference variables and tie it back to your example in the section Time is More Relative than You Think.

In the section Optional References, your example on dynamic references is missing the policy on the @Reference annotation.  In this section, you also bring up checking for null, but don’t tie that example specifically to the optional reference.  Also, I would add a recommendation and example for using AtomicReference for the dynamic reference.

In the section Tracking Multiple Services when you annotate the volatile List, doesn’t the @Reference annotation need the dynamic policy set, or does DS infer it from the volatile keyword?

In the section Tracking Multiple Services -> Multiple Services per Key, why is the Holder class needed?  It seems more straightforward to simply use final ConcurrentMap<String, Set<Foo>> multis = new ConcurrentHashMap<>().  The rest of the logic is unchanged.

In the section IOServer, why doesn’t if (isInterrupted()) call interrupt()?

In the section Asynchronous API’s, why use an OSGi Promise when you can use a CompletableFuture?

That’s it.

Bryan

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Raymond Auge]

If i may, I think this level of detailed (and great) feedback would be perfect in a pull request! :D (since I know that Peter is super busy these days)

Sincerely,

- Ray

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

[Timothy Ward]

I do have one answer to the earlier questions.

In the section Asynchronous API’s, why use an OSGi Promise when you can use a CompletableFuture?

Don’t use CompletableFuture because the API is horrible. They tried to fix Future, which had too few methods, by adding every conceivable combination of method parameters for every conceivable method. OSGi Promises have a much more sensible, readable set of primitives. I would always choose a Promise over a CompletableFuture.

Regards,

Tim

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

[Peter Kriens]

+100

CompletableFuture was designed after a heavy night drinking or they had no clue.

Kind regards,

Peter Kriens

[Peter Kriens]

On 24 Nov 2016, at 15:29, Bryan Hunt <bh...@mac.com> wrote:

Hi Peter,

Overall a great article!  Thanks for putting this together.

The section on Atomically Closing was confusing.  I understand what you are doing in the close(), but don’t see how that has anything to do with unbind and deactivate.

You can dynamically unbind a reference, in that case you must close the wrapper for that reference. However, if you deactivate the object, you need to close all. There can in certain cases be a race condition between the two cases.

In the section Guarantees from DS -> Ordering, The wording of 3. Activate "Only if all methods are called is the activate method calls” is a bit confusing.

In the section Static References, it would be helpful to explain why you don’t need to use volatile for reference variables and tie it back to your example in the section Time is More Relative than You Think.

I tried to … can you suggest wording?

In the section Optional References, your example on dynamic references is missing the policy on the @Reference annotation.  In this section, you also bring up checking for null, but don’t tie that example specifically to the optional reference.  Also, I would add a recommendation and example for using AtomicReference for the dynamic reference.

The dynamic policy is added by the volatile keyword. AtomReference was a good pattern in the old days but with field injection it lost its value.

In the section Tracking Multiple Services when you annotate the volatile List, doesn’t the @Reference annotation need the dynamic policy set, or does DS infer it from the volatile keyword?

Yup. Same as the optional. volatile == dynamic policy

In the section Tracking Multiple Services -> Multiple Services per Key, why is the Holder class needed?  It seems more straightforward to simply use final ConcurrentMap<String, Set<Foo>> multis = new ConcurrentHashMap<>().  The rest of the logic is unchanged.

I guess it is a style issue but I prefer to have a wrapper object in those case so I can do things in methods and add more fields if necessary.

In the section IOServer, why doesn’t if (isInterrupted()) call interrupt()?

Because the interrupt flag is not cleared. the interrupted() method or isInterrupted(true) clear the interrupt flag.

In the section Asynchronous API’s, why use an OSGi Promise when you can use a CompletableFuture?

Because they suck! :-) The Promise is much better designed.

Kind regards,

Peter Kriens