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. 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. In any case, the example worked well to expose the fsemaphore bug. -- 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/20200523193815.179%40sirmail.smtp.cs.utah.edu.
