Timeline for Determine concurrent access to a function
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 7, 2019 at 21:57 | comment | added | Josiah | A macro actually wouldn't materially change the point made. You don't care about whether two threads are technically running the same function. You do care whether they are might be doing mutually dangerous operations, and being in the same function is shorthand for that. Therefore, whether the check is technically before or after the function call is less important than that it is before any dangerous stuff. | |
| Jun 7, 2019 at 15:04 | comment | added | j b | @sudorm-rfslash that's a fair point. I think the key is to state the assumptions of the checker clearly. I'm also thinking that a better overall solution may to be use a macro that wraps the function call rather than trying to measure inside the function itself. | |
| Jun 7, 2019 at 15:02 | comment | added | Josiah | The core of the claim here is that while your construction can tell you that you do have a problem, it cannot tell you that you do not. That is to say, it is possible to run your thing in testing a dozen times and it be fine, but the code could still exhibit race conditions that happen on run number twenty-four. Therefore although it can be helpful, especially for detection of frequent collisions, it should not be relied on alone. | |
| Jun 7, 2019 at 14:31 | history | became hot network question | |||
| Jun 7, 2019 at 13:37 | comment | added | sudo rm -rf slash | "i.e. after the construction of ConcurrencyChecker" ... this is where our assumptions differ. the pc could point to the first instruction in the function, which in these examples would be the ctor of the checker. the pc is clearly in the function, but the checker hasn't run yet. threads can block anywhere for any amount of time | |
| Jun 7, 2019 at 13:11 | comment | added | j b |
@sudorm-rfslash I'm a bit confused by what you mean here. How is it possible for i threads to enter the function (i.e. after the construction of ConcurrencyChecker) without numInstances being incremented i times? Since it is incremented during object construction and decremented during destruction don't we have determinism for measuring concurrent execution of the function body following construction of ConcurrencyChecker (marked /* Function body */ in the code?
|
|
| Jun 7, 2019 at 12:24 | comment | added | sudo rm -rf slash | This is a non deterministic detector. Even if the caller does everything she can to cause concurrent access, it might not get caught by your detector (even your test is not deterministic -- suppose the ith thread yields for 10*i seconds immediately after being called and there are no other breaks). In my opinion, you're better off proving the fn can/cannot be called concurrently at design time rather than trying to debug it at runtime. There are tools that can automate this. | |
| Jun 7, 2019 at 7:47 | comment | added | j b |
@TobySpeight good catch. cerrMutex is actually unneeded and just residual from before I broke ConcurrentPrint into its own class.
|
|
| Jun 7, 2019 at 7:37 | answer | added | Josiah | timeline score: 6 | |
| Jun 7, 2019 at 7:28 | comment | added | Toby Speight |
Are you missing a definition of ConcurrencyChecker::cerrMutex?
|
|
| Jun 7, 2019 at 6:20 | review | First posts | |||
| Jun 7, 2019 at 7:28 | |||||
| Jun 7, 2019 at 6:17 | history | asked | j b | CC BY-SA 4.0 |