commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [SCXML] onentry executable content parallel to further transitions
Date Mon, 15 Sep 2014 14:32:36 GMT
On 11-09-14 11:30, Johannes Wienke wrote:
> 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.

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 just increase CPU load or with a larger sleep statement
> I will add an unwanted delay in processing.

Maybe you can try my suggestion above: extending SCXMLExecutor probably will 
allow for a trivial intermediate solution for this.

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

Done, thanks for pointing this out.

>
>> 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.
Like I mentioned above, other use-cases might want/need to manage such event 
coordination themselves. So while it probably is feasible to add an optional and 
example wrapper solution handling this automatically on behalf of clients, it 
must leave room for other more domain specific solutions as well.


>
> Cheers,
> Johannes
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message