2.11 refinement/explanation

[anthonyvdotbe]

§2.11 says:

A Subscriber MUST make sure that all calls on its onXXX methods happen-before [1] the processing of the respective signals. I.e. the Subscriber must take care of properly publishing the signal to its processing logic.

I believe this rule:

1. should drop the second sentence, since it's not adding anything new to the rule. Moreover, it has caused me much more confusion than that it helped me understand the rule.
2. needs explanatory examples, illustrating different ways of processing, and showing why each way obeys this rule:

• synchronous processing, referring to the JLS: If x and y are actions of the same thread and x comes before y in program order, then hb(x, y).
• asynchronous processing by starting a new Thread, referring to the JLS: An action that starts a thread synchronizes-with the first action in the thread it starts. and If an action x synchronizes-with a following action y, then we also have hb(x, y).
• asynchronous processing using an ExecutorService, referring to its Javadoc: Memory consistency effects: Actions in a thread prior to the submission of a Runnable or Callable task to an ExecutorService happen-before any actions taken by that task, which in turn happen-before the result is retrieved via Future.get().
• asynchronous processing using a concurrent collection, such as ConcurrentLinkedQueue, referring to its Javadoc (and AsyncSubscriber as a concrete example): Memory consistency effects: As with other concurrent collections, actions in a thread prior to placing an object into a ConcurrentLinkedQueue happen-before actions subsequent to the access or removal of that element from the ConcurrentLinkedQueue in another thread.

Given these examples and the JLS/Javadoc references, one can clearly see what this rule demands, and how, in fact, it's easy to obey it.

There are still some things I don't understand concerning this rule:

• why does the AtomicBoolean on in the AsyncSubscriber example refer to this rule? In other words, why isn't the use of the ConcurrentLinkedQueue sufficient to obey this rule? To me it suggests that multiple items cannot be processed concurrently, but I don't see how this would be implied by this rule (or why this would be a requirement at all).
• what did @akarnokd mean with: In practice, we had to make sure there was no reordering in the sequence over an async boundary.? To me it suggest that items must be processed in the order they are received. But again: I don't see how this would be implied by this rule, or why this would be a requirement in the first place.

[viktorklang]

Hi @anthonyvdotbe,

My sincerest apologies for the delay in responding here. I'm currently swamped with other stuff.
I'm looking forward to have some time to really wrap my head around your excellent Issues over the next week(s).

Please don't hesitate in opening further Issues when you find something which would benefit from clarification.

Cheers,
√

[anthonyvdotbe]

Hi @viktorklang

No need to apologize, I understand. Actually I have night school exams coming up myself, so there's no hurry.

Kind regards,
Anthony

[viktorklang]

Apologies for the delay here, AFAICT fixed in #339