On Mon, 2005-07-04 at 15:19 +1000, Peter Moulder wrote:
On Sat, Jul 02, 2005 at 12:18:52PM +0200, Ralf Stephan wrote:
Also the order of nulling+freeing is reversed to make sure there is no race condition (not sure if necessary but hey).
Surely this is unnecessary unless we are multi-threaded, or some other asynchronous event (signal handler?) can access gr->color here.
There aren't. Even if there were, reordering the operations wouldn't help. It'd be necessary to establish a memory barrier (e.g. using one of the standard locking primitives).
With no memory barrier established, compiler and CPU would be free to arbitrarily reorder the operations, and even without that, threads on other CPUs may see the operations totally differently because of cacheing.
Really it'd be necessary to establish a critical section around the whole bit, too, in the likely case that the code were racing with anything beyond another thread also trying to free the buffer.
-mental