BrowserUK,
Threads / shared / queues opens up a lot of possibilities that will really simplify my application. Already I see how one of my select(...,timeout)'s will go away. The other one needs a little more thought, but I think it can be restructured along the lines you suggest.
Under the fork-exec model, the five processes start with static copies of the same variables. A change to any variable requires propagating it to the other processes. This is done with udp datagrams. Each of the four worker process talks only to the "supervisor", who relays the messages (see below).
There are three basic messages passed between processes:
Request: ("get", $item, "") or ("set", $item, $state)
Response: ( "status", $item, $state)
Four of the processes do actual work, while the "supervisor" primarily just relays messages. The get and set messages are one-to-one, but the status message must be cc'd to the other processes so everyone knows the current status of $item. To cut down on the number of messages, the supervisor doesn't cc anyone if the status has not changed. The supervisor also provides the "watchdog" function, waking up every 60 seconds. An external digital i/o PLC will do an "automated scram" if it has not received a command from the software in 120 seconds, so the watchdog function keeps it running. (Yes, the operator can initiate a "manual scram" too.) The watchdog also requests the status of any physical hardware device if no one else has asked for it in the last 60 seconds.
Enter threads / shared / queues: If I make %status a shared variable, then all the status response messages go away, since each thread will have access to the current $status of any item. Supervisor's job is now reduced to just doing the watchdog function: sleep(60); do_watchdog(); No select needed.
The gets and sets are unidirectional one-to-one messages, so each worker thread can have an incoming queue which it monitors with Q->dequeue. A thread can issue a get or set request directly to the receiving thread by doing a Q->enqueue. Now all the udp messages go away.
The other select(...,timeout) process needs some more thought. It must asynchronously process get and set requests, while waking up every second to implement the PID (proportional, integral, derivative) ramp-and-soak algorithm, and turn Solid State Relays on and off. As you suggest, waking up every 1/10 second to check the Q will not consume much CPU, and 1/10 sec is probably asynchronous enough.
Question: Do the shared variables and queues need locking?
With a single CPU, I suspect the shared variable updates are atomic, but the Q operations might not be. With multiple or multi-core CPUs, things could possibly happen at exactly the same time, so problems might occur. Thoughts?
If it ain't broke, don't fix it. Well, I've already converted to threads, the system works perfectly and consumes 0% CPU. Implementing shared variables and queues will take some work, but the benefit would be easier maintenance - there's a lot of complicated logic that would simply go away.
I've got some other questions that I'll post in new messages.
AH HA MOMENT: I got really tired of typing in all the P and /P tags to make my PerlMonks posts look pretty. Then I realized that if I composed them in Dreamweaver and typed in the "display" area, DW would make a new paragraph every time I hit the enter key. Much easier!
In reply to Re^4: Win32 - flock() not FIFO?
by hennesse
in thread Win32 - flock() not FIFO?
by hennesse
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |