[libvirt] [PATCHv2] threads: add one-time initialization support
Matthias Bolte
matthias.bolte at googlemail.com
Sun Apr 24 10:14:29 UTC 2011
2011/4/23 Eric Blake <eblake at redhat.com>:
> mingw lacks the counterpart to PTHREAD_MUTEX_INITIALIZER, so the
> best we can do is portably expose once-only runtime initialization.
>
> * src/util/threads.h (virOnceControlPtr): New opaque type.
> (virOnceFunc): New callback type.
> (virOnce): New prototype.
> * src/util/threads-pthread.h (virOnceControl): Declare.
> (VIR_ONCE_CONTROL_INITIALIZER): Define.
> * src/util/threads-win32.h (virOnceControl)
> (VIR_ONCE_CONTROL_INITIALIZER): Likewise.
> * src/util/threads-pthread.c (virOnce): Implement in pthreads.
> * src/util/threads-win32.c (virOnce): Implement in WIN32.
> * src/libvirt_private.syms: Export it.
> ---
>
> v2: change WIN32 implementation to use lower-level primitives available
> to mingw and older windows, rather than higher level but newer INIT_ONCE.
>
> Meanwhile, I noticed that gnulib has an LGPLv2+ 'lock' module that
> provides a lot of multi-threading primitives for both pthreads, pth,
> and mingw; maybe we should think about rewriting threads.c in terms
> of gnulib and only have one implementation, rather than maintaining
> pthread and mingw in parallel?
> +int virOnce(virOnceControlPtr once, virOnceFunc func)
> +{
> + if (!once->complete) {
> + if (InterlockedIncrement(&once->init) == 1) {
> + /* We're the first thread. */
> + func();
> + once->complete = 1;
> + } else {
> + /* We're a later thread. Decrement the init counter back
> + * to avoid overflow, then yield until the first thread
> + * marks that the function is complete. It is rare that
> + * multiple threads will be waiting here, and since each
> + * thread is yielding except the first, we should get out
> + * soon enough. */
> + InterlockedDecrement(&once->init);
> + while (!once->complete)
> + Sleep(0);
> + }
> + }
> + return 0;
> +}
Compared to the gnulib lock module version, this one is less complex
and I don't get why gnulib uses 3 states for the init and complete
variables and an additional lock object. The only reason could be to
minimize the time busy waiting in the while loop.
> +
> +struct virOnceControl {
> + long init; /* 0 at startup, > 0 if init has started */
> + volatile long complete; /* 0 until first thread completes callback */
> +};
MSDN docs about InterlockedIncrement suggest that init should be volatile too.
ACK, with init marked volatile.
Matthias
More information about the libvir-list
mailing list