------- Comment #6 from pcarlini at suse dot de 2005-10-13 09:06 -------
(In reply to comment #5)
> This locking code looks really strange to me.
>
> void
> release() // nothrow
> {
> if (__gnu_cxx::__exchange_and_add(&_M_use_count, -1) == 1)
> {
> dispose();
> __glibcxx_mutex_lock(_M_mutex);
> __glibcxx_mutex_unlock(_M_mutex);
> weak_release();
> }
> }
>
> Anyway. Any chance this could be commented? What's being attempted?
Indeed, it is strange. I will ask to Jonathan to add some comments, as soon
as his new assignment paperwork is on file and he can contribute freely. What
I can tell you now, is that quite a few of those weird contortions resulted
from exchanges with Peter Dimov and the need to add memory barriers in some
places, we are using empty critical regions as a surrogate of that.
> Also, Paolo, if you've been able to reproduce this problem, I'd appreciate a
> test case that demonstrates the issue checked in with the patch. Then, if the
> locking bits get changed in the future we won't run into this regression if
> things aren't quite right.
Agreed. A reliable testcase is not available, at the moment. Consider, however,
that in the simpler case would require either parsing the output of valgring,
or rather bigger piece of code linked with -lpthreads that would fail in a
non-deterministic way after some time in some unpredictable way.
All in all, not an easy task, as often happens with concurrency, sadly.
> As it stands now, I have no idea what the problem is, or was, other than the
> mutex was never initialized.
Yes a testcase would be nice. The mutex is certainly not initialized, this is
certainly a serious bug that we can fix now.
--
pcarlini at suse dot de changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24244
