Re: Unexpected value-at for NULL'd pointer with pthreads

[Jeffrey Walton <noloader at gmail dot com>]

On Fri, Aug 21, 2015 at 1:31 AM, Kyle Harper <kylejharper@gmail.com> 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