From: Jim Peters (jim_at_uazu.net)
Date: 2002-03-20 13:13:24
Dave wrote:
> What might be nice is that if we abstract this out far enough, the
> underlying implementations can be different depending on our varying
> needs ... ... (perhaps nothing more than OpenDataStream(),
> ReadDataStream(), WriteDataStream(), and CloseDataStream() methods.
> This way, the underlying transport can be anything from sockets to
> shared memory to whatever.
Can I ask you to rethink this approach -- this still assumes that you
will run every module in a separate thread. If you consider a simple
chain A->B->C, then, for example, thread A generates data, calls its
WriteDataStream() which sticks it in shared memory and then blocks
thread A. Now thread B unblocks because data is available to it,
processes the data, and writes it before blocking. Then thread C
unblocks to read the data and complete the chain. If you look at
this, a lot of the time is actually spent in context changes between
the threads.
A much more efficient method is to have a process() call on the
modules, and let a single thread manage them all. It can watch for
when data is available for various modules, and call them as
appropriate. For instance, in this example it would end up calling
A->process(), B->process(), C->process(). That way the
thread-switches are reduced to the cost of function calls. Also, you
guarantee that everything is locked in sync -- there is no chance for
some thread to get 100 samples behind the others.
I've done some work on this kind of thing previously, and once a
network of modules has been set up with predictable input, you can
actually pre-calculate the sequences of ->process() calls you need to
make to get the whole network to run through.
However, this is only good for in-memory stuff. If you want modules
running all over a network, then this is going to be no good at all.
> Each sensor can inherit this class since each sensor will have one,
> and only one, data stream.
This depends on whether you regard each EEG signal as a separate data
stream. It might be useful to do so for some kinds of
interconnections. For example, in the audio module stuff I looked at
a while back, a stereo channel is often represented as two mono
channels so that you can route the mono channels independently.
Jim
-- Jim Peters (_)/=\~/_(_) jim_at_uazu.net (_) /=\ ~/_ (_) Uazú (_) /=\ ~/_ (_) http:// B'ham, UK (_) ____ /=\ ____ ~/_ ____ (_) uazu.net
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:43 BST