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