Re: [SCXML] onentry executable content parallel to further transitions
Hi,
thanks for the feedback.
I could actually make this work by extending the executor and everything
seems to work fine.
Cheers,
Johannes
On 09/15/2014 04:32 PM, Ate Douma wrote:
> On 11-09-14 11:30, Johannes Wienke wrote:
>> On 09/09/2014 04:28 PM, Ate Douma wrote:
>>> On 08-09-14 18:59, Johannes Wienke wrote:
>>>> On 09/07/2014 10:31 PM, Ate Douma wrote:
>>>>> Actually, Commons SCXML already uses an event queue (one for internal
>>>>> events and one for external events).
>>>>> It is however the responsibility of separate client threads to only
>>>>> use
>>>>> the executor #addEvent methods and only use a single client thread for
>>>>> actual execution and event triggering on the state machine.
>>>>> The bug you encountered was in the Commons SCXML *internal*
>>>>> delivery of
>>>>> events which likewise (now) should use #addEvent but still used the
>>>>> #triggerEvent method instead. This should now be fixed.
>>>>
>>>> Ok, assuming I am always using addEvents to fill the event queue, what
>>>> is the correct pattern for a worker thread that then calls
>>>> triggerEvents()? As far as I can tell from the implementation, this
>>>> method returns immediately in case the queue is currently empty. Hence,
>>>> implementing something like
>>>> while (true) {
>>>> executor.triggerEvents();
>>>> }
>>>> should result in a loop wasting one CPU in case no external events need
>>>> to be processed? This sounds wrong to me.
>>>
>>> I think that is typically what you'll need to do, or else add some
>>> 'eventAdded' notification and coordination yourself (see below).
>>
>> Wouldn't it be much nicer from a user perspective if the executor could
>> offer something like waitForNextEvents() or
>> waitUntilEventsInExternalQueue()? Depending on the use case, this is
>> much easier to implement internally than externally.
>
> Yes, that might be possible to add.
> But note that the current implementation isn't 'done' yet and several
> aspects of the current specification with regards to the event IO
> processor [1] aren't
> completely implemented yet.
> That functionally was initially on my plan for milestone 3 in the
> roadmap [2], but I already discovered I need some of this earlier on,
> and I've already started on some further internal refactoring and
> enhancements in this area.
>
> But even when completed, such 'automatic' event coordination and
> execution still should remain an optional feature only to allow for
> other solutions where this coordination better be done within custom and
> domain specific client code.
>
> My goal anyway is to first get the event IO processing in place as
> required by the specification.
> But of course I'm also open for contributions and development support in
> general :)
>
> [1] http://www.w3.org/TR/scxml/#eventioprocessors
> [2]
> http://commons.apache.org/proper/commons-scxml/roadmap.html#Milestone_3:_External_communications_support
>
>
>>
>> Moreover, since SimpleScheduler now uses addEvent, too, I cannot even
>> know all events that enter the state machine, or am I wrong? So I am
>> doomed to implement a busy waiting loop.
>
> Yes, in the current implementation you'll have to coordinate this yourself.
> It should be trivial though to extend the SCXMLExecutor for your purpose
> to get 'notified' about such #addEvent invocations.
>
>>
>>> The initiating thread creating/owning the executor/engine instance
>>> likely also should be responsible for managing the statemachine
>>> execution: instantiating and then starting with go(), continuing with
>>> triggerEvents(), and if needed resetting through reset().
>>>
>>> Other threads (as well as the 'owner' thread) can/should only add events
>>> to the queue through addEvent(Event), including threads dispatched from
>>> the engine itself.
>>>
>>> Only a single owner thread should 'trigger' subsequent engine
>>> processing.
>>> You can use executor.hasPendingEvents() to prevent the overhead of a
>>> trivial amount of CPU cycles, but executor.triggerEvents() with an empty
>>> queue will only impose a minimal overhead anyway.
>>
>> But if I know that there are currently no pending events, then I can't
>> do anything else then polling in a busy loop. Either I have to do this
>> quite often and ju
Re: [SCXML] onentry executable content parallel to further transitions
On 09/09/2014 04:31 PM, Ate Douma wrote:
> On 09-09-14 11:20, Johannes Wienke wrote:
>> Hi,
>>
>> On 09/08/2014 10:07 PM, Martin Gainty wrote:
>>> StringTokenizer st = new StringTokenizer(event);
>>>
>>> int tkns = st.countTokens();
>>> TriggerEvent[] evts = new TriggerEvent[tkns];
>>> for (int i = 0; i < tkns; i++) {
>>> executor.triggerEvents();
>>>
>>
>> But then I have to implement a custom logic to restart that loop once
>> new events arrive after it finished once. Moreover, this doesn't look
>> thread-safe.
>
> Hi Johannes,
>
> Wrong list or did you intend to raise a question about the above?
> The context isn't clear to me and the code example confusing and not
> complete/correct either.
Got this as an answer to my question but it seems that answer did not
end up on the list.
Cheers,
Johannes
--
Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University
Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307)
Phone: +49 521 106-67277
signature.asc
Description: OpenPGP digital signature
Re: [SCXML] onentry executable content parallel to further transitions
Hi,
On 09/09/2014 04:28 PM, Ate Douma wrote:
> On 08-09-14 18:59, Johannes Wienke wrote:
>> On 09/07/2014 10:31 PM, Ate Douma wrote:
>>> Actually, Commons SCXML already uses an event queue (one for internal
>>> events and one for external events).
>>> It is however the responsibility of separate client threads to only use
>>> the executor #addEvent methods and only use a single client thread for
>>> actual execution and event triggering on the state machine.
>>> The bug you encountered was in the Commons SCXML *internal* delivery of
>>> events which likewise (now) should use #addEvent but still used the
>>> #triggerEvent method instead. This should now be fixed.
>>
>> Ok, assuming I am always using addEvents to fill the event queue, what
>> is the correct pattern for a worker thread that then calls
>> triggerEvents()? As far as I can tell from the implementation, this
>> method returns immediately in case the queue is currently empty. Hence,
>> implementing something like
>> while (true) {
>> executor.triggerEvents();
>> }
>> should result in a loop wasting one CPU in case no external events need
>> to be processed? This sounds wrong to me.
>
> I think that is typically what you'll need to do, or else add some
> 'eventAdded' notification and coordination yourself (see below).
Wouldn't it be much nicer from a user perspective if the executor could
offer something like waitForNextEvents() or
waitUntilEventsInExternalQueue()? Depending on the use case, this is
much easier to implement internally than externally.
Moreover, since SimpleScheduler now uses addEvent, too, I cannot even
know all events that enter the state machine, or am I wrong? So I am
doomed to implement a busy waiting loop.
> The initiating thread creating/owning the executor/engine instance
> likely also should be responsible for managing the statemachine
> execution: instantiating and then starting with go(), continuing with
> triggerEvents(), and if needed resetting through reset().
>
> Other threads (as well as the 'owner' thread) can/should only add events
> to the queue through addEvent(Event), including threads dispatched from
> the engine itself.
>
> Only a single owner thread should 'trigger' subsequent engine processing.
> You can use executor.hasPendingEvents() to prevent the overhead of a
> trivial amount of CPU cycles, but executor.triggerEvents() with an empty
> queue will only impose a minimal overhead anyway.
But if I know that there are currently no pending events, then I can't
do anything else then polling in a busy loop. Either I have to do this
quite often and just increase CPU load or with a larger sleep statement
I will add an unwanted delay in processing.
> Because only the 'owner' thread does (and may do) the actual execution
> of the engine, you're guaranteeing, and protecting (yourself!), no
> concurrent statemachine processing will happen. The (current) executor
> intendedly does NOT enforce this (as you noticed) with synchronization
> blocks or otherwise.
Ok, got it. Could you please fix up the respective FAQ entry that is at
least confusing in that respect:
https://commons.apache.org/proper/commons-scxml/faq.html#many-threads
> It remains that your owner thread will have to use some timer based
> triggering of the executor, but that is typical when dealing with
> multiple thread coordination/synchronization. Or else you could consider
> extending/intercepting the executor to 'notify' your owner thread when
> new events are added to the external queue.
> But with that you'll enter a domain specific implementation, not easily
> generalizable in Commons SCXML (although I'm happy to review patches ;) ).
Is this really domain specific? Something simple as using notify on an
object available to clients whenever new events enter the external queue
would already be sufficient to implement a proper synchronization system
without busy waiting. And this would be a huge improvement several use
cases that I can imagine.
Cheers,
Johannes
--
Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University
Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307)
Phone: +49 521 106-67277
signature.asc
Description: OpenPGP digital signature
Re: [SCXML] onentry executable content parallel to further transitions
Hi,
On 09/08/2014 10:07 PM, Martin Gainty wrote:
> StringTokenizer st = new StringTokenizer(event);
>
> int tkns = st.countTokens();
> TriggerEvent[] evts = new TriggerEvent[tkns];
> for (int i = 0; i < tkns; i++) {
>executor.triggerEvents();
>
But then I have to implement a custom logic to restart that loop once
new events arrive after it finished once. Moreover, this doesn't look
thread-safe.
Cheers,
Johannes
--
Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University
Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307)
Phone: +49 521 106-67277
signature.asc
Description: OpenPGP digital signature
Re: [SCXML] onentry executable content parallel to further transitions
Hi,
thanks for the feedback work on this!
On 09/07/2014 10:31 PM, Ate Douma wrote:
> Actually, Commons SCXML already uses an event queue (one for internal
> events and one for external events).
> It is however the responsibility of separate client threads to only use
> the executor #addEvent methods and only use a single client thread for
> actual execution and event triggering on the state machine.
> The bug you encountered was in the Commons SCXML *internal* delivery of
> events which likewise (now) should use #addEvent but still used the
> #triggerEvent method instead. This should now be fixed.
Ok, assuming I am always using addEvents to fill the event queue, what
is the correct pattern for a worker thread that then calls
triggerEvents()? As far as I can tell from the implementation, this
method returns immediately in case the queue is currently empty. Hence,
implementing something like
while (true) {
executor.triggerEvents();
}
should result in a loop wasting one CPU in case no external events need
to be processed? This sounds wrong to me.
Cheers,
Johannes
--
Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University
Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307)
Phone: +49 521 106-67277
signature.asc
Description: OpenPGP digital signature
Re: [SCXML] onentry executable content parallel to further transitions
Hi, On 08/29/2014 12:39 PM, Johannes Wienke wrote: > we are currently evaluating commons scxml in the trunk version for our > purposes. On thing that confused us is the fact that transitions from a > state can already occur while that state's onentry executable content is > still processing. Hence, we end up with more parallelism than expected. > > Is this the intended behavior? > > From the SCXML specification I actually cannot find anything that either > allows or prevents this interpretation. So I am also curious how this > behavior is justified wrt. to specs. Following up on this: We have found a statement in the SCXML specification that disallows the current behavior. In section 4.10 the specification states: "Note that SCXML treats the executable content triggered by a transition as a single blocking operation and that no events are processed until all the executable content has completed. For example, when taking a transition into state S, the SCXML processor will not process any events or take any transitions until all handlers in S have finished." This is definitely not the case right now when using multiple threads to trigger events. From a design point of view: why do the client threads that trigger events directly process the whole event transition logic instead of using an internal event queue and a processing thread as proposed by the SCXML specification? Cheers, Johannes -- Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307) Phone: +49 521 106-67277 signature.asc Description: OpenPGP digital signature
Re: [SCXML] onentry executable content parallel to further transitions
On 09/01/2014 09:23 AM, Ate Douma wrote: > Great to see you looking into commons scxml! > I've been away for a while on holiday so sorry for the late feedback on > this and the other issues you reported. I haven't had time yet to dive > into these but will look into them shortly. Great! Thank you very much! Johannes -- Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307) Phone: +49 521 106-67277 signature.asc Description: OpenPGP digital signature
[SCXML] onentry executable content parallel to further transitions
Hi, we are currently evaluating commons scxml in the trunk version for our purposes. On thing that confused us is the fact that transitions from a state can already occur while that state's onentry executable content is still processing. Hence, we end up with more parallelism than expected. Is this the intended behavior? From the SCXML specification I actually cannot find anything that either allows or prevents this interpretation. So I am also curious how this behavior is justified wrt. to specs. Kind regards, Johannes -- Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307) Phone: +49 521 106-67277 signature.asc Description: OpenPGP digital signature
