Modify

Opened 9 years ago

Closed 9 years ago

#2391 closed Bugs (fixed)

interprocess_recursive_mutex doesn't work interprocess

Reported by: Sergey Samsonik <serge_98@…> Owned by: Ion Gaztañaga
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 (1)

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

Download all attachments as: .zip

Change History (5)

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

Attachment: bug.cc added

source code to demonstrate the problem

comment:1 Changed 9 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 9 years ago by Ion Gaztañaga

Milestone: Boost 1.37.0To 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 9 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 9 years ago by Ion Gaztañaga

Milestone: To Be DeterminedBoost 1.38.0
Resolution: fixed
Status: newclosed

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Ion Gaztañaga.
The resolution will be deleted.

Add Comment


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

 
Note: See TracTickets for help on using tickets.