|
Message-ID: <1407409391.24324.365.camel@eris.loria.fr>
Date: Thu, 07 Aug 2014 13:03:11 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: Explaining cond var destroy [Re: C threads, v3.0]
Am Donnerstag, den 07.08.2014, 12:52 +0200 schrieb Szabolcs Nagy:
> * Jens Gustedt <jens.gustedt@...ia.fr> [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 ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.