On Fri, Aug 21, 2015 at 1:31 AM, Kyle Harper <kylejharper@xxxxxxxxx> wrote: > Hey all, this is my first post to this list so please forgive (and > correct me on) any faux pas with my question below. I'm hoping I'm > either missing something simple or someone can explain in deeper > detail the inner workings of what gcc is doing to create my dilemma > below. I think Jonathan has the right troubleshooting idea, if you can get it to duplicate under instrumented code and tools. >From the sounds of it, it sounds like its the same issue that used to occur with the double-checked locking initialization pattern. See, for example, http://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/. If this is the case, then use a memory barrier to ensure the write completes after setting the pointer to NULL. Maybe something like: #if defined(_MSC_VER) # pragma intrinsic(_ReadWriteBarrier) # define MEMORY_BARRIER() _ReadWriteBarrier() #elif defined(__INTEL_COMPILER) # define MEMORY_BARRIER() __memory_barrier() #elif defined(__GNUC__) || defined(__clang__) # define MEMORY_BARRIER() __asm__ __volatile__ ("" ::: "memory") #else // # error "Unknown compiler" #endif if (list->pool[mid]->id == (*buf)->id) { for (int i=mid; i<list->count - 1; i++) list->pool[i] = list->pool[i+1]; list->count--; free(*buf); *buf = NULL; MEMORY_BARRIER(); lock__release(lock_id); printf("%d : free() and null done\n", pthread_self()); break; } Jeff
