I disabled examples/Makefile:113-119 (as indicated above). I don't immediately see what (else?) you mean by "Use makefiles from example folder i.e. ../examples/parallel_for/seismic/Makefile or XCode. Or remove the line:).", because the seismic example was visible without any correction to the file you mention (although only for an instant, so maybe it should be made to show a longer time interval or so).

For the vertical orientation, I presume that drawing_area is supposed to represent the pixels from left to right and then from top to bottom (not documented of course...)? That has to be flipped upside down for use with OpenGL (which assumes bottom to top), perhaps using glPixelZoom(1,-1) (with the appropriate raster-position corrections of course).

Correction sent through http://threadingbuildingblocks.org/submit-contribution.

Confirmed, thanks!

Perhaps you could make the "seismic" example run for a fixed amount of time, though? It used to take several seconds on my previous computer, it progresses (assumedly) at glacial speed when running from a remote X client (even slower than pover, which speeds past it like a snail), but on my current computer I would literally miss it if I were to blink at the wrong time. On the upside, this is the first time I've noticed that it actually does something interesting if I click on the window (after I adapted Makefile to make it run longer)...

That's what I did. Could polygon_overlay and seismic be making a round trip per pixel, as opposed to an entire rectangle for tachyon etc.? Just a side issue, of course, but while we're on the subject...

(Added 2013-05-13) The side issue was about slowness on X across a network with significant latency.

What happened in developer release tbb41_20130425oss compared to release 4.1 update 3? Now I don't see seismic even if I don't blink, and the parallel tachyon examples seem to appear fully computed (way superscalar)!

(Added) Sorry, I should have tried 4.1 update 3 again before posting this, because it shows the same changes, although I don't see how (surely that Thunderbolt-related update didn't cause this?). The superscalar thing is quite disconcerting: maybe there's a delay in bringing up the windows that takes more of a bite out of the shorter times, and perhaps the computation is also faster before the window is shown? Anyway, seismic and tachyon are clearly not enough of a challenge anymore on recent hardware, so at least seismic should run for a specific or unlimited time instead of an arbitrary number of frames (increasing that would be too much for slower machines), because otherwise you'll never be able to see what happens when you click on the window...

Oddly enough I can't reproduce the problem anymore (so I also can't test your hypothesis), but please go ahead and make cocoa_update atomic if that seems appropriate (don't use volatile). I don't really understand the protocol (if cocoa_update communicates between threads, shouldn't it then be more like an epoch instead?), but it also doesn't really matter (so I didn't look very carefully).