This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pthread_mutex_t initializer idiom


Hi Benjamin,

I'm still trying to unify some of the atomics and concurrency code, and
remove duplicates.

I see this idiom a lot:

	  __gthread_mutex_t temp = __GTHREAD_MUTEX_INIT;
	  _M_mutex = temp;

Can somebody explain to me why we are doing this instead of:

_M_mutex = __GTHREAD_MUTEX_INIT;

?


There is a rather old and funny comment at line 586 of rope:

{
// Do not copy a POSIX/gthr mutex once in use. However, bits are bits.
__gthread_mutex_t __tmp = __GTHREAD_MUTEX_INIT;
_M_c_string_lock = __tmp;
}


I think the idea is using __GTHREAD_MUTEX_INIT, which, in principle should be used only on static things, on a mutex that certainly doesn't exist yet, __tmp, then do a "bit by bit" copy to the mutex in the object (not yet in use) and hope for the best. In other terms, It seems to me, that is the best we can do to deal with two different sources of theoretical undefined behavior: 1- __GTHREAD_MUTEX_INIT on non-static things; 2- Copying (Posix) mutexes is undefined (in principle, also when not in use, I'm afraid...).

I would suggest showing this code (again) to someone really knowing well the internals of the various kinds of mutexes which GCC supports...

Paolo.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]