Timeline for Plagued by multithreaded bugs
Current License: CC BY-SA 3.0
31 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 8, 2018 at 8:41 | comment | added | Nathan | "The current developers on the team are very smart, but mostly junior in terms of experience" - Tbh it's nice you have smart people, but this is the category of problems you will get if you only hire them when they're cheap. | |
| Apr 7, 2018 at 9:31 | answer | added | Brendan | timeline score: 0 | |
| Apr 6, 2018 at 13:43 | answer | added | gnasher729 | timeline score: 1 | |
| Apr 4, 2018 at 16:14 | answer | added | Erhannis | timeline score: 2 | |
| Sep 15, 2016 at 13:31 | comment | added | Bradley Thomas | Better languages would not allow developers to get into hard situations so easily | |
| Sep 10, 2016 at 17:26 | comment | added | MauganRa | As @DeadMG's answer points out, you can run into problems with the first two code examples even when not using threads at all. The code simply assumes that m_pBar != nullptr always holds, even though the existence of Foo::Shutdown() clearly indicates otherwise. | |
| Mar 9, 2016 at 16:14 | comment | added | Phil Lello | Is it even vaguely possible to nuke the existing libraries and replace with new code that the current team both understand, maintain, and document? Sounds like the biggest issue is a loss of knowledge (not necessarily capability) in the team. | |
| Oct 12, 2012 at 11:30 | comment | added | GlenPeterson | I would replace "Erlang" with "Functional Language" in the above comments, but even in a procedural language you can minimize mutability as gnat said AND minimize side effects. Martin Odersky's course introduces a technique for this that I hadn't seen before - model your objects in terms of their functions instead of their state. E.g. instead of storing a value, think of answering a question. A set can be implemented as a set of rules for what could be in that set, and work very well without ever actually containing any objects! | |
| Oct 12, 2012 at 2:06 | answer | added | Tim Williscroft | timeline score: 2 | |
| May 27, 2012 at 17:30 | comment | added | Zachary K | I have no idea, the last time I looked at C++ was 20 years ago. But I would rather use a language where actors are built in. I know it works in Erlang | |
| May 25, 2012 at 20:32 | comment | added | Giorgio | @Zachary K: Do you think that using a proper C++ actor implementation can alleviate the problem? | |
| May 25, 2012 at 17:57 | history | edited | koncurrency | CC BY-SA 3.0 | deleted 44 characters in body |
| May 25, 2012 at 16:14 | answer | added | kevin cline | timeline score: 9 | |
| May 25, 2012 at 15:55 | answer | added | Giorgio | timeline score: 7 | |
| May 25, 2012 at 15:20 | answer | added | Seth Noble | timeline score: 9 | |
| May 25, 2012 at 14:34 | comment | added | Zachary K | @DeadMG that is true, if you don't know how to use your tools well, you will produce bad software | |
| May 25, 2012 at 12:48 | comment | added | DeadMG | @ZacharyK: It can be useful. But more relevantly, if you simply don't use the tools that the model you're using gives you, there's no reason to assume that you'll use the tools actor model gives you, either. Switching model won't help if you can't program your way out of a wet paper bag. | |
| May 25, 2012 at 11:17 | answer | added | back2dos | timeline score: 7 | |
| May 25, 2012 at 11:08 | comment | added | Zachary K | @DeadMG I would contend that shared state concurrency is inherently prone to weird corner cases and should be avoided. But Hey I wrote a book on Erlang | |
| May 25, 2012 at 10:21 | comment | added | DeadMG | @ZacharyK: His problem has nothing to do with the language and everything to do with the fact that his code makes extremely poor utilization of the available features and libraries. | |
| May 25, 2012 at 10:16 | comment | added | Zachary K | If you want to see concurrency done well use Erlang! In truth what you want is some form of a shared nothing actor model where the weird corner cases are going to be eliminated. | |
| May 25, 2012 at 9:55 | answer | added | DeadMG | timeline score: 29 | |
| May 25, 2012 at 9:44 | answer | added | JesperE | timeline score: 1 | |
| May 25, 2012 at 8:56 | comment | added | ratchet freak | shouldn't the LeavLock() be in a finally block? | |
| May 25, 2012 at 8:52 | comment | added | quickly_now | Welcome to multi-thread hell. I've been writing multi-thread / paralell programs for > 20 years, in Ada, Occam, C++. It's never easy, everything requires very careful thought, and anyone who says "its easy just do X" is a fool who does not really understand what is going on. Good luck. | |
| May 25, 2012 at 8:32 | answer | added | Klaim | timeline score: 1 | |
| May 25, 2012 at 8:19 | comment | added | gnat | what works well for me is to get rid of mutability whenever possible. When I see mutable object changing state in order to pass the new value, I try to refactor that into passing a new immutable object holding changed value instead. If object initialization is done safely, this guarantees the absence of data races - quite a relief | |
| May 25, 2012 at 8:15 | history | tweeted | twitter.com/#!/StackProgrammer/status/205935027832356864 | ||
| May 25, 2012 at 8:08 | comment | added | Tom Squires | Some people when confronted with a problem think I will use multi threading. Now they have twolm probes | |
| May 25, 2012 at 8:02 | history | edited | koncurrency | CC BY-SA 3.0 | added 1 characters in body |
| May 25, 2012 at 7:55 | history | asked | koncurrency | CC BY-SA 3.0 |