On 24. 05. 20 3:38, Matthew Flatt wrote: > At Sat, 23 May 2020 18:51:23 +0200, Dominik Pantůček wrote: >> But that is just where the issue is showing up. The real question is how >> the counter gets decremented twice (given that fsemaphores should be >> futures-safe). > > I found a configuration that triggered the bug often enough on my > machine. Yes, it was a dumb mistake in the implementation of > fsemaphores. In your example, it wasn't so much that the counter > fsemaphore was decremented twice, but that the lock fsemaphore could go > negative --- so it didn't actually lock. > > I've pushed a repair.
Thank you for the repair (and good idea with the test case). > > > FWIW, after looking at this example more, I see why it's still not > enough in principle to make a thread that waits on the result of > `do-start-workers` or to run `do-start-workers` after the enqueue > loops. The `start-workers` function can run a dequeue loop after > starting a future to do the same, and before touching that future. So, > the dependencies aren't as linear as I thought before. > > If your real code looks anything like this, consider using a CAS > operation, like `box-cas!`, instead of an fsemaphore as lock for the > queue. The queue's use of an fsemaphore for counting and signaling > seems fine, though. > Yes, the real code is a binary tree of futures. However each future performs a lot of fixnum/flonum operations. At first I was surprised that you are basically suggesting using spinlocks (busy-wait loops) instead of futex-backed (at least on Linux) fsemaphores. That is a waste of CPU time... But yes, CAS-based locking outperforms fsemaphores locking and distributes the work way more evenly. Now when I see it in action and look at the source it kind of makes sense as the spinlock does not need to wait long and does not cause any re-scheduling (which is the reason why I get so uneven counts with fsemaphore-based locking). > In any case, the example worked well to expose the fsemaphore bug. > Probably expect to see more in the future :) Dominik -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/9fdcb07a-a596-fc84-5529-4517f6b8b1fd%40trustica.cz.