3 ms·

I think the crucial part are the retries, which havent been mentioned. In general, you cant assume your code will always read the new checksum before entering

I think the crucial part are the retries, which havent been mentioned. In general, you cant assume your code will always read the new checksum before entering the critical section, unless you synchronize it. That is, when leaving the critical section you have to make sure that all threads waiting to enter it will recompute the hash. But, from the entering thread's perspective, you never know when youll be forced to recompute. So you've got to wait on the lock. And recompute when you are woken up. I'm not stating what they've written is wrong. Just for me it's a bit vague and looks like potential race condition.

jacoblambda 6y ago
I don't think that would enter a race condition. 1. All the zones start precomputing the checksums using a worker pool. Changes are fed into the pool with the change time stamped. The workers don't store the checksum if a newer checksum is already present. 2. The zones enter the lock/critical section. At this point new changes are no longer added to the work queue and must wait until the lock exits. The worker pool continues to process the queue. 3. The work queues are empty and the checksums are compared between zones. Those that match are "locked in" and those that don't are set aside for the next time the zones enter the lock/critical section. 4. The zones exit the lock, a timer starts, and step 1 starts again. At no point here would there be a race condition. As long as non-matching changes are pruned and retried in the next cycle, progress will be made. In certain conditions the retries could degrade overall performance but consensus is eventually achieved and the system continues to make progress.