Unqualified thoughts said: > I think it would be a not-very-good idea to add a bottleneck er mutex to > threading NTPsec, Linux worked hard to kill off their global lock IIRC.
The current code is single threaded so adding a global lock is just to preserve correctness until we fix the code to use finer grained locking. > A 24 block byte should suffice for the client-supplied data to the NTPv3/4 > server threads, NTPv2 would probably need the same with perhaps a dozen bytes > differing. You need a lock on that block in order to prevent the server from getting half the data from before an update and the other half from after the update. (Remember, the old code was single threaded.) If NTPv3 needs anything that isn't in the NTPv3/4 block, we should add it rather than creating another block of data. My expectation is that the client (write) side would collect all the data, then grab a (spin?) lock, copy over the data, then release the lock. Similarly on the server (read) side, it would grab the lock, copy out the data, then release the lock. > IIRC there was a draft over at IETF to have the client port hop instead of > sticking to 123/UDP. Yes. I think that will be easier to do after we support threads. The idea is that each client thread would do the packet exchange, then get the global lock and call into the existing code. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
