I have been floundering for a long time with a project that is too overwhelming. I want to control instruments, over a 100 different kinds, about 10 or less at a time, with various protocols.

I was thinking that if each instrument was a small daemon that polled a DB every few seconds for a batch of commands+times they would run at, then the daemons could be accurately coordinated but still only loosely coupled and a big problem could be broken down into smaller blocks. Is this s dumb idea? Thanks for reading-Patrick

A simpler (and probably more efficient) answer would be to write a scheduler daemon that would poll the database and launch the appropriate controller daemons as needed. This would simplify the design and should also drastically improve runtime performance.

-PatP

Thanks Pat

A scheduler would be a lot simpler but I have to have two way communication. I was thinking that since the instruments would be sending data points to the DB then they might as well read and set flags as well, such as abort, or commands + times such as at 3:26 plot.

Thanks again

There is absolutely no reason why the task-specific threads can't do just that. I'm just suggesting that you create a scheduler thread that reads the schedule and all it does is start other threads with any apporpriate parameters. The worker threads do exactly one task, such as contraol a specific class of machine for a particular operation which may be a single millidsecond or multiple days, depending on the needs of that worker thread.

This is more flexible in many ways. There is only one scheduler that needs to monitor the database. The worker threads do exactly one task. Only active threads are running. If more than one of the same type of task needs to run (for example two machines doing the same task), just start two instances of that task on their own threads.

-PatP