On 03/07/2014 08:25 AM, John Kasunich wrote: > Not so. Just because addval and deltalim are independent does not mean > that no concurrency risks exist. I pointed out in my analysis that > deltalim is accessed multiple times during one invocation of > make_pulses. If it is possible for update_freq to run concurrently > with or interrupt make_pulses, then deltalim should be copied to a > local and subsequent accesses should use the local copy. This is a > simple fix, but until it is done, update_freq and make_pulses ARE > subject to priority and/or non-preemption conditions. Also, I suspect > that deltalim is not the only variable that needs such treatement.
Please excuse my drive-by comment. I rarely post, but have been following this thread fairly closely. You comment about "fixing" by copying deltalim to a local and then using the local copy for subsequent accesses. But what about compiler optimization, reordering of instructions by the CPU, and cache effects? I don't think you are guaranteed to get what you seem to be counting on. You need to add explicit synchronization. If you haven't already seen the two part video, "C++ and Beyond 2012: Herb Sutter - atomic<> Weapons", I think you'll find it enlightening. -- Chris Lesiak Principal Design Engineer, Software LI-COR, Inc. chris.les...@licor.com Any opinions expressed are those of the author and do not necessarily represent those of his employer. ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
