From: Benjamin F. <ben...@he...> - 2012-03-01 21:59:41
|
On Donnerstag, 1. März 2012, Greg White wrote: > Hm, interesting, it's not my field at all, but what strikes me is you > characterise behaviour that I would have called a feature, as needing a > "solution". You can call it a feature, but as features go this is one of the more dangerous sort. I like to compare this to pointer arithmetic and manual memory management. Certainly useful for system level core software, but maybe not so suitable for high-level application programming. (I think Marty started the project in Java instead of C/C++ for a reason...) For an example of what kind of subtle problems using such a feature can introduce into your code, see the this message to tech-talk and the thread that follows it: http://www.aps.anl.gov/epics/tech-talk/2010/msg00154.php One point in the exchange I want to highlight is the following, because I expect answers similar to the one Tim Mooney gave: From: Benjamin Franksen <ben...@be...> Date: Fri, 26 Feb 2010 00:20:28 +0100 > On Donnerstag, 25. Februar 2010, Tim Mooney wrote: > > On 2/25/2010 7:43 AM, Benjamin Franksen wrote: > > > It remains to draw practical conclusions for how to avoid such race > > > conditions in SNL code. Should we generally be wary of pvPut and > > > monitor to the same state variable? Could the compiler warn us about > > > that? Or is this too restrictive? [*] > > Wrong take-home message, though. If you had written this in C, > > your first thoughts would probably have been something like this: > > > > "Hmmm... two tasks; shared resource; better implement a mutex" > > [...] this was not the problem: > access to the state variable is atomic just fine, it's just that event > (wake up) and test for the value are not. This is why two event flags, or > even two state variables assigned to the same PV work fine. As would two > semaphores for the C program. To avoid possible misunderstandings: the original program did not crash, nor was the shared data corrupted, so adding a mutex to protect the variable alone would have been useless (as well as redundant). The crash is caused by an assertion that expresses what I thought must be true and was not. The original program simply did something wrong, and it was /very/ hard to find the cause. A possible solution, had this been a normal imperative program, would have been to include both the waiting for the event /and/ the test for the value inside a critical region. Note, however, that waiting (indefinitely) inside critical regions is problematic in itself, as it may introduce the danger of deadlock. Cheers Ben [*] Andrew said to that: yes, that should indeed be avoided and people who use the pattern most probably were just lucky so far. ________________________________ Helmholtz-Zentrum Berlin für Materialien und Energie GmbH Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V. Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph Geschäftsführerin: Prof. Dr. Anke Rita Kaysser-Pyzalla Sitz Berlin, AG Charlottenburg, 89 HRB 5583 Postadresse: Hahn-Meitner-Platz 1 D-14109 Berlin http://www.helmholtz-berlin.de |