Modify

Ticket #2391 (closed Bugs: fixed)

Opened 6 years ago

Last modified 5 years ago

interprocess_recursive_mutex doesn't work interprocess

Reported by: Sergey Samsonik <serge_98@…> Owned by: igaztanaga
Milestone: Boost 1.38.0 Component: interprocess
Version: Boost 1.35.0 Severity: Showstopper
Keywords: interprocess fork pthread Cc:

Description

The recursive mutex tests current thread using detail::get_current_thread_id(), which in turn uses pthread_self(). The latter function returns thread id that unique in context of a process. (As least in CentOS 4.6 'm using.) This results in threads from different processes not being synchronized. Sometimes it results in asserts (in debug build) or exceptions (in release). Attached is a small shared memory test that uses fork() which led me to finding the problem. Environment and test's output:

$ g++ -v Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux Thread model: posix gcc version 3.4.6 20060404 (Red Hat 3.4.6-10) [sergeys@sergeys-vm32 boosttest]$ g++ bug.cc -o bug -I /mnt/builder/3rdParty/boost/v35.0/include -L /mnt/builder/3rdParty/boost/v35.0/lib32 -l rt

$ uname -a Linux sergeys-vm32 2.6.9-78.0.1.ELsmp #1 SMP Tue Aug 5 11:02:47 EDT 2008 i686 i686 i386 GNU/Linux

$ g++ bug.cc -o bug -I /mnt/builder/3rdParty/boost/v35.0/include -L /mnt/builder/3rdParty/boost/v35.0/lib32 -l rt

$ ./bug parent pthread_self -1208224064 child pthread_self -1208224064 bug: /mnt/builder/3rdParty/boost/v35.0/include/boost/interprocess/sync/emulation/interprocess_recursive_mutex.hpp:97: void boost::interprocess::interprocess_recursive_mutex::unlock(): Assertion `detail::equal_thread_id(detail::get_current_thread_id(), m_nOwner)' failed. Aborted Done child

Please note, that when built on different system (CentOS 5), the test runs without assertion. But the mutex still doesn't protext the code as intended.

Attachments

bug.cc Download (672 bytes) - added by Sergey Samsonik <serge_98@…> 6 years ago.
source code to demonstrate the problem

Change History

Changed 6 years ago by Sergey Samsonik <serge_98@…>

source code to demonstrate the problem

comment:1 Changed 6 years ago by Sergey Samsonik <serge_98@…>

A little clarification,

/* Thread process-shared synchronization is not supported. */ #define _POSIX_THREAD_PROCESS_SHARED -1

in /usr/include/bits/posix_opt.h on my system causes boost/interprocess/sync/emulation/interprocess_recursive_mutex.hpp to be used, which doesn't work with multiple processes as explained above.

comment:2 Changed 6 years ago by igaztanaga

  • Milestone changed from Boost 1.37.0 to To Be Determined

Thanks for the report. The code for "generic" recursive mutex suposses thread id is unique for all system threads, which is true for windows but not for POSIX (some implementations yes, others not). So the solution is not easy and boost 1.37 is around the corner, so it must delayed for a future release. Suggestions and comments are welcome.

comment:3 Changed 6 years ago by Sergey Samsonik <serge_98@…>

This is not a showstopper for me any longer since the systems I'm working with now (CentOS/RedHat 4.5+) implement Posix shared mutexes, even thought /usr/include/bits/posix_opt.h states it otherwise. There's another /usr/include/nptl/bits/posix_opt.h header, which defines correct values for these systems. -I/usr/include/nptl compiler option addressed the problem in this case.

I don't know it it's possible or how, a solution (at least a temporary one) may be disabling generic (interprocess) recursive mutexes on systems where thread ids are not unique.

Also, the problem looks very similar to the one in ticket #1390 here.

comment:4 Changed 5 years ago by igaztanaga

  • Status changed from new to closed
  • Resolution set to fixed
  • Milestone changed from To Be Determined to Boost 1.38.0

Changed code so that the thread identifier is an structure with the pid and the thread id.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.