Hello again with futures! I started working on futures-based workers and got quickly stuck with a dead-lock I think does not originate in my code (although it is two semaphores, 8 futures, so I'll refrain from strong opinions here).
I implemented a very simple futures-friendly queue using mutable pairs and created a minimal-deadlocking-example[1]. I am running racket 3m 7.7.0.4 which includes fixes for the futures-related bugs I discovered recently. Sometimes the code just runs fine and shows the numbers of worker iterations performed in different futures (as traced by the 'fid' argument). But sometimes it locks in a state where there is one last number in the queue (0 - zero) and yet the fsemaphore-count for the count fsemaphore returns 0. Which means the semaphore was decremented twice somewhere. The code is really VERY simple and I do not see a race-condition within the code, that would allow any code path to decrement the fsema-count fsemaphore twice once the worker future receives 0. I am able to reproduce the behavior with racket3m running under gdb and get the stack traces for all the threads pretty consistently. The deadlock is apparently at: 2 Thread 0x7ffff7fca700 (LWP 46368) "mfqueue.rkt" futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x5555559d8e78) at ../sysdeps/nptl/futex-internal.h:183 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). Any hints would be VERY appreciated! Cheers, Dominik [1] http://pasterack.org/pastes/28883 -- 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/5dcf1260-e8bf-d719-adab-5a0fd9378075%40trustica.cz.
