This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH: Configure libstdc++-v3 against gthr.h

>(2) Add the constructor, if required and allowed by the platform.
>    This might preclude some STL uses.  In particular, the user must
>    avoid global objects that contain STL containers, etc.  But the
>    C++ standard already makes it hard to use global variables.
>(3) Force user to do initialization setup.  Actually, the user
>    has the same problem here, where does he stick his code to
>    ensure it runs before any global constructor that may have
>    run and assumed the mutex existed.

Below is the exact patch I am proposing to automate initialization for
platforms that only offer __GTHREAD_MUTEX_INIT_FUNCTION in their
gthr.h abstraction layer.  David helped inspire this design choice,
but I take full blame, if I bungled it in the implementation.

It checks with no libstdc++-v3 regressions on a target that usually
provides __GTHREAD_MUTEX_INIT (but whose libstdc++-v3-staged
gthr-default.h file was hand edited to appear to only offer run-time
initialization of a mutex via __GTHREAD_MUTEX_INIT_FUNCTION).

Selected non-portable examples that use the rest of the POSIX thread
interface and STL (at least one of these has been posted) were also
tested with good results.  The only question that remains in my mind
is whether this technique is portable enough across g++ platforms.

This takes the STL code unconditionally from option (3) to option (2)
only when option (1) was not available.

Index: libstdc++-v3/include/bits/stl_threads.h
RCS file: /cvs/gcc/egcs/libstdc++-v3/include/bits/stl_threads.h,v
retrieving revision 1.4
diff -c -5 -r1.4 stl_threads.h
*** stl_threads.h	2001/06/08 03:53:34	1.4
--- stl_threads.h	2001/06/08 09:30:28
*** 299,308 ****
--- 299,318 ----
  struct _STL_mutex_lock
  // GCC extension begin
  #if defined(__STL_GTHREADS)
    __gthread_mutex_t _M_lock;
+   // There should be no constructor in this path given the preferred
+   // usage rules stated in the comment above.
+   // We define a constructor since absolutely required for this
+   // platform unless we were to delegate the initialization problem
+   // entirely to the user.  In that case, how would we even alert the
+   // user to the need to do the initialization step?
+   _STL_mutex_lock (void) { _M_initialize(); }
+ #endif
    void _M_initialize()
    // There should be no code in this path given the usage rules above.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]