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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5dcf1260-e8bf-d719-adab-5a0fd9378075%40trustica.cz.
