[omniORB] Re: OmniEvents and threading

Bruce Fountain fountainb@switch.aust.com
Tue Jan 14 05:57:02 2003


On Tuesday 14 January 2003 04:47, bjorn rohde jensen wrote:
>   I also worry a lot about the foot-print of the
> implementation, which is rather at odds with all the
> fancy QoS options, TypedEvents and such, i would like
> omniEvents to support.
>   Any thoughts, system requirements ideas and
> experiences with respect to omniEvents and event
> services in general are quite welcome:)

Some thoughts:

* I would avoid thread-per-consumer. In any large installation
  you are going to bog down the process considerably in
  servicing a large number of threads. Instead I would go
  with a pool of "flushers". The flusher looks for a
  consumer with a non-empty queue which is not already
  flushing and which has waited longest for a flush. It seizes
  the consumer (semaphore locked) and starts pushing the
  events to the consumer. A badly behaved consumer
  monopolises only one thread (which is using no cpu
  anyway) leaving the other threads to look after the
  other consumers. The size of the pool can be a QoS
  parameter

* Rather than copying each event into each consumer's
  queue, consider using a reference-counting approach.
  When an event arrives it is stored and a reference to
  the event is appended to each per-consumer queue.
  Each time an event is popped from the per-consumer
  queue the refcount for the event is decremented, until
  the event is deleted when its refcount falls to zero. This
  would reduce considerably the memory required per
  queued event and eliminate unnecessary copies. 

* A more efficient approach still is to store incoming events
  in chronological order. Instead of a per-consumer queue
  each ProxyPushSupplier just keeps track of the index of
  the last pushed event. Keeping track of refcounts gets
  trickier though because you need to cope with consumers
  who arrive or depart while events are being stored etc.
  You could have a periodic reaper thread who retrieves
  the last-pushed-event index from each ProxyPushSupplier,
  determines the oldest of these, and deletes all events up
  to this index

-- 
Bruce Fountain (fountainb@switch.aust.com)
Senior Software Engineer
Union Switch and Signal Pty Ltd
Perth Western Australia
tel: +618 9256 0083