Clear questions and runnable code get the best and fastest answer |
|
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Time to bring out one of my favourite computing quotes once again (and it's more applicable than the last time I did :-): A computer is a state machine. Threads are for people who can't program state machines. - Alan Cox Processors handle commands sequentially, it is impossible for any currently existing CPU core to handle two instructions at the same time (well, this is not strictly true for SMT processors, but things get hairy enough here to ignore that for this discussion). Thus, the number of operations that can theoretically be executed at exactly the same time on your machine will be limited by the number of CPU cores on that same machine. Even then, synchronising several processes to execute exactly the same command at the same time on different cores is a hard task and likely not possible without reaching into your OS kernel (in fact, I'd be surprised if it were possible on a non-RT OS at all). Now, if (as indicated in your post) you are using "date" to confirm the processes are running at the same time this probably means you don't actually need them to run at the exact same microsecond but have a certain leeway. You'd need to tell us what you're actually trying to do and what kind of delay in execution is acceptable before we can make any sensible suggestions. If, for example, the task is non-blocking (i.e. does not involve IO) and quick, simple sequential processing in a loop may be sufficient. All dogma is stupid. In reply to Re: multi threading
by tirwhan
|
|