Am Donnerstag, den 07.08.2014, 12:52 +0200 schrieb Szabolcs Nagy: > * Jens Gustedt [2014-08-07 09:50:51 +0200]: > i havent followed all the discussions so i dont know if > this is libc internal only or exposed to the user (who > does the free) > > but the locking behaviour exposed to the user should > be such that this pattern works: > > mutex_lock(obj->lock); > c = --obj->refs; > mutex_unlock(obj->lock); > if (!c) > free(obj); yes, but these were not the assumptions that were made upthread. The assumption was that a "waiters" counter had fallen to 0, not a reference count. > if it does not work then there will be hard to debug bugs absolutely > > The easiest way to assure that, would be to impose that the "real" > > data object that the thread lock, unlock, wait etc operations would > > use would always have to be malloced. > > > > For C threads this can be done by mtx_init and cnd_init. They would > > be allocating the dynamic object, set "refs" to 1 and set a link to > > that object. For mtx_t and cnd_t dynamic initialization is imperative. > > > > dynamic allocation per mutex or cond var sounds bad sure, but for the moment I am out of ideas, unfortunately Jens -- :: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::