sizeof() segfault and mutex initialization?

Loren James Rittle rittle@latour.rsch.comm.mot.com
Fri Feb 21 21:39:00 GMT 2003


In article <20030219232332.6d8afd41.bkoz@redhat.com> Benjamin writes:

I have little comment to add re 1).  After gthr.h is included,
__gthread_mutex_t must be a complete type.  If you find a situation
where this is not true, then we have a bug to fix in a concrete
implementation of the abstraction layer.

>> 2) gthr does not implement a __gthread_mutex_init () function, only a 
>> static initializer. However we need to create 1-n mutexes - one per bin 
>> - during initialization code. How can this be done?

include/bits/stl_threads.h has working code directly using the gthr
abstraction.  include/bits/stl_alloc.h has code to indirectly use the
gthr abstraction.  See below for an idea.

>> Is it possible/ok to call __gthread_objc_mutex_allocate?

Please don't.  gthr-rtems.h and gthr-vxworks.h don't support that
extension of the base gthr abstraction layer.

> Ouch. Loren?

Ouch indeed.  The gthr abstraction layer is tough to use precisely
because some platforms don't allow some expected features.  Can you
consider using _STL_mutex_lock which hides all of the complexity of
the direct use of a gthr mutex?  Here are idiomatic usages which I
believe should work on all platforms (John David Anglin and I worked
hard to make this so, although it may inefficient and we may have
retained some usage aspects only because SGI STL code did it a
particular way):

#include <bits/c++config.h>
#include <bits/stl_threads.h>

static std::_STL_mutex_lock l __STL_MUTEX_INITIALIZER;

int main()
{
  l._M_acquire_lock();
  // code related to mutex region l
  l._M_release_lock();
}

#include <cstdlib>
#include <bits/stl_threads.h>

int main()
{
  std::_STL_mutex_lock l __STL_MUTEX_INITIALIZER;
  std::_STL_mutex_lock* lp =
    (std::_STL_mutex_lock*) std::malloc(sizeof (std::_STL_mutex_lock));
  *lp = l;

  lp->_M_acquire_lock();
  // code related to mutex region l
  lp->_M_release_lock();
}

In the second case, do not touch l before the assignment.  Based on
portability notes, never give l automatic storage and then use it
directly.  In the second case, it is assumed the setup code actually
goes into a constructor or some other path known to execute before
other threads have visibility.

If you really want to use the gthr abstraction directly, I will have
to refer you to the include/bits/stl_threads.h code.  BTW, I didn't
recommend this idea to Phil (when he did the generic atomicity.h
header work) due to a circular header reference problem.  However, I
think an allocator should layer on top of stl_threads.h.

Regards,
Loren



More information about the Libstdc++ mailing list