[Embedlets-dev] Re: Thread prioritization.
Status: Alpha
Brought to you by:
tkosan
|
From: Andrzej J. T. <an...@ch...> - 2003-03-08 14:36:08
|
> 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! Not every platform we are targeting provides this capability, so we might have to provide different implementations on different platforms. The TINI doesn't have thread priorities, I believe. However, this might be a nice solution for those platforms that do provide RTOS thread prioritization. What I would do is have the send() method raise it's thread priority higher than the async event queue handling threads, send the sync event, then return it's priority to it's starting value. That would effectively block the async threads from executing during the sync event propagation. > 1. The sendEvent(Event) method being thread-safe for synchronous events I believe it is already. > 2. Events would store their own consumer collection (or an event per > consumer) I've thought about this already. This is a non-trivial thing to implement compared to how it is currently done (separate event queue and registered consumer collection, with matching done when the event is "ready" to be propagated, immediately with sync, handled later by the async event dispatcher thread). The problem you run into with having events track their own collection of consumers is that a consumer can be registered or deregistered at any time, which implies that you have to scan the whole list of queued events every time a consumer registration changes, and update each events individual consumer collection. With wildcard matching on event types on the part of consumers, this involves a LOT of duplicate checking (since a consumer could easily appear in more than one event's collection), lots of overhead, and some pretty complex threaded code (with lots of thread synchronization issues), without a lot of benefit to show for it. So I've left it simple at the moment, keeping separate track of event queues and registered consumers. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |