From: Joel Eriksson (jen_at_ettnet.se)
Date: 2002-01-25 00:28:13
On Thu, Jan 24, 2002 at 12:36:09AM +1000, John Morrison wrote:
> > When I wrote ElectricGuru, it was initially multithreaded
> > and then I changed it to single because it turned out not to
> > offer any advantages in this context, but it did contribute
> > the disadvantage of increasing overhead.
> With a single threaded program you really need to have a path through the
> code. The software we are designing will have "plug in" modules that we
> haven't even thought about yet but which the program will need to handle.
> We don't' want the user to have to recompile the software after loading a
> new module so multi threading is the only way I can see of doing it.
Actually, you can use independent plugin-modules in a single-threaded
event-driven program too. In general, there are three programming models
for managing independent tasks in an application. Multiple processes
that communicates via some sort of IPC (very common under Unix),
multiple threads (more common under Windows), and an event-driven
process that uses non-blocking I/O and multiplexes all tasks in a
single thread.
Event-driven programs are usually very efficient and they are not
susceptible to the subtle race-conditions that inevitably arise in
large multi-threaded applications, they scale with actual activity,
does not require expensive context-switches and demands less memory.
Multiprocess / multithreaded applications scale better with hardware
upgrades (faster CPU, more CPUs, more RAM) but event-driven programs
usually performs very well with limited resources. A hybrid solution
may be appropriate to combine the advantages of each model.
In this particular case I would recommend making the data acquisition
and processing completely event-driven, it would probably be best to
use a thread / threads for the GUI-handling though.
I don't believe we have anything to win by writing a device driver
to manage the serial port at interrupt-level or something like that
though, if we can't process data as fast as it's coming then we'll
have a problem no matter what. Using select() or its correlate
depending on OS and API to wait until data is available for reading
is most certainly enough.
So, about Moritz statement that the interface code to transfer data
from the EEG to the program is one of the simplest parts, that Jim
Meissner seems to have his doubts about, I agree fully with Moritz
and if working code to achieve this is needed to convince Meissner
I don't have any problems supplying this either. I also think that
the hardware is not really needed to start developing the software,
if we don't have a working EEG for supplying data we can use the
logfiles from Meissners webpage or perhaps write a program that
generates a fake EEG-datastream.
The biggest problem with this is probably keeping the programmers
motivated, but it is in no way undoable or "inappropriate" to build
or at least make plans for the software at this stage. Perhaps it
is a good idea to move discussions about software design to a separate
list though (EEGS?), as long as the project as a whole does not become
split up and move in different directions but I don't really think
that will happen.
> John
-- Joel Eriksson
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:37 BST