RE: [Embedlets-dev] Re: Sync vs Async

[Christopher S. <cs...@oo...>]

>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Chris observes:
>
> > That all makes sense for events that can afford to fail (logs, user
> > interaction etc.) For those that cannot there needs to be a queue-bypass
> > path that can complete in a given amount of time. Fortunately the
> > synchronous event stack depth would be deterministic since a given event
> > would have a known path based on the consumers that are registered. The
> > last event in the path may be asynchronous as in a logging event, user
> > notification. This mix and match of sync/async events is central to real
> > time operation with external client processes.
>
> I absolutely agree....and Synchronous event sending is now
> implemented.  The
> next version to go up (this weekend) will have that in place.
>
> > But you would use an interrupt driven event to notify critical embedlets
> > that something needs to be done NOW! This kind of event could occur on
> > sub-millisecond to an hour or more interval. The important thing is that
> > there is a mechanism to define the mission critical event and guarantee
> > its immediate delivery. This way the developer does not have to
> 'punt' too
> > early in the game because Embedlets cannot deliver!
>
> Yup....but I see the interrupt-generation and initial receipt as being a
> device driver issue (JAPL?) which will then send a Synchronous
> event to an
> Embedlet to do something useful with the interrupt notification.
>
> I'll give some thought to a way of grabbing a global async thread lock so
> that all other threads get blocked while the synchronous event is being
> propagated, for the ultra-critical events.  Otherwise, even a synchronous
> event propagation can be pre-empted by an async thread execution.

What is the problem with bypassing the container involvment and relying on
the RTOS thread priortization to manage the thread switch? That is what it
is there for!

This would involve
1. The sendEvent(Event) method being thread-safe for synchronous events
2. Events would store their own consumer collection (or an event per
consumer)
3. The sendEvent(Event) just turns around and invokes the
4. Async events would signal the background queuing thread to wake up and do
it's thing.


>
> > This makes the most sense in core Embedlet communication. This makes the
> > 'wires' a solid connection between produce and consumers and ensures
> > prompt processing of events. Async events will be very important as well
> > to off load communication between more loosely coupled
> processes to lower
> > priority services.
>
> Yup!  And we now have both.
>
> > We should probably put together a 'When to use Sync/Async
> events' document
> > based on this discussion thread.
>
> For sure....this would be very useful.
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView,
> The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on
> major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>