3 ms·
FOr multi/parallel issues, debuggers are practically worthless. Logging + threadid + timestamps and something to organize/sort the output is about all you can
by AtlasBarfed 4y ago
FOr multi/parallel issues, debuggers are practically worthless.
Logging + threadid + timestamps and something to organize/sort the output is about all you can do.
Debugging parallel/multithread code is a badly unsolved problem in programming, and something that TDD, which tends to focus on single thread units, also doesn't really address.
I think it would require something that can built on-the-fly visualized reconstructions of what happens, almost like a starcraft game where each unit is a process/thread and it replays events from the log in reversible forward/backward slo-mo. Interactions or message passing can be attacks on other "units".
Or some dynamic graph/process diagram builder that links together the processes when message passing occurs or flashes/changes color as interal process state changes.
Good news everybody! All your code should be built with the intent of multithreading or parallelism to some degree, since that is all that we can really do with the remaining scaling from Moore's law, and really has been for a decade now.
Edit: oh I forgot. Debugging multithread isn't even a single-VM issue now. Even more common is visualizing interactions across many many VMs thanks to microservices.
- samsquire 4y agoWhen writing multithreaded code I need some visualization of where everyone could be. It's expensive invariant management. There is a partial order that is fine and there is a partial order that is not fine. If we could define the orders with a sorting function and apply them to events in real time that would be perfect. In effect my partial order cannot overlap your partial order. This is the grounds of the YATA algorithm. Happens before relation is really powerful. But it needs to be visible to other processes.
- AtlasBarfed 4y agoSounds like code proofs and other things which I last saw in the 1990s in school. But I see how once you have to cross the rubicon to parallel processing, to make it sane, you'll need to rethink the old ways from simpler serial execution programming.
- samsquire 4y agoI wrote a lock free algorithm. Every thread monitors every other thread's thread Id and the lowest thread Id wins. When a thread finishes its work it updates the thread Id to Integer.MAX_INTEGER so someone else can have a go. Readers block writers and writer's block readers so it's not very good. But it's a start. It's hard to update a linked list as you could accidentally partially update it while it is being iterated. I could allow parallel edits and reads if the read is after the edit. So I would need to introduce a different variable for checking while reading. It needs to be logically after the write. HTTPS://GitHub.com/samsquire/compare-and-swap-sort