Talk:Checkpoint synchronization: Difference between revisions

no edit summary
m (fix typo)
No edit summary
Line 5:
::: That said, I'd be careful about appropriating FFT specifically to demonstrate "[[Checkpoint synchronization]] with a communication phase"...for something like that, a more appropriate task might be something like map/reduce with an otherwise meaningless function call on each data block. (I wanted to say "generic function call", but that might force a distinction between languages that have (or can fake) first-class functions, and languages that don't/can't.) I like the FFT idea, but I don't care to have distinct tasks for a FFT map/reduce-like task, and FFT in general. Ditto for matrix block multiplication, for the same reasons; it's not helpful for site organization to demonstrate the same thing (such as a transform or algorithm) in multiple places. --[[User:Short Circuit|Michael Mol]] 10:46, 11 August 2010 (UTC)
: The principle is that there is a checkpoint group (which a thread may ask to join and leave) and on synchronization, nobody completes the checkpoint synch operation until all members of the group complete it. It's use might be if you've got a bunch of threads doing some kind of physical simulation, with a checkpoint barrier at the end of each simulation time step. –[[User:Dkf|Donal Fellows]] 13:53, 11 August 2010 (UTC)
 
Is 'checkpoint synchronization' the best name for this task? On wikipedia, there's [an article http://en.wikipedia.org/wiki/Barrier_(computer_science)#Threads_synchronization_primitive] entitled Barrier with a sub-heading of Thread synchronization primitive? It seems to fit the description of this task.