Why, if you want two actions to happen within a specified time of each other, are you putting them in threads? Especially as the actions are SNMP traps, which are UDP messages for which there is no reply, so no IO wait for the second event to overlap.
You are trying to arrange for two threads to synchronise, which whilst possible if your running on a multiprocessor system, is a very hard (and pointless) exercise.
Even if you are running on multi-processor hardware, unless it is multi-homed also, your carefully synchronised traps will be serialised at the network stack.
And if ir is multi-homed, unless the destination hardware, and every node in between is also multi-processor and multi-homed, one of them will serialise the traps as they pass through.
Finally, if any other traffic is using any of the cable runs or any of the intervening nodes, it will almost certainly delay one trap relative to the other. Even if you succeed in causing the traps to be passed onto the network with specific timing, there is no guarentee, and absolutely no chance(*) that they will arrive at their destination(s) with that same timing.
Two dual-processor, dual-homed systems connected back to back in complete isolation might maintain the timing, but even that is unlikely.
Finally, with UDP messages, if you just sent them serially from a single thread, it is almost unthinkable that they would not be transmitted within one second of each other. Even if your outbound connection was via 1200 baud modem, unless your data packets are pretty big, you could expect to transmit many more than two UDP messages serially, from a single thread within 1 second.
There just doesn't seem to be any good reason for doing what you are trying to do. Please correct me if I am not seeing the whole picture?
In reply to Re: sleep and timing?
by BrowserUk
in thread sleep and timing?
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |