Boost C++ Libraries: Ticket #4524: interprocess::interprocess_semaphore consumes cpu while waiting

attachment set

Tue, 10 Aug 2010 19:28:08 GMT

attachment → sem.cc

When main thread sleeps in sleep(), thread thr1 does wait() on semaphore and consumes cpu while waiting.

Tue, 10 Aug 2010 19:31:51 GMT

My system:

% uname -a FreeBSD gpr.nnz-home.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r211020M: Sun Aug 8 11:06:03 MSD 2010 gpr@…:/usr/obj/usr/src/freebsd-head/sys/GPR amd64

% g++ -v Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD]

boost 1.43 from freebsd ports

Rohit Joshi — Wed, 11 Aug 2010 21:40:05 GMT

Event I have the same issue. When I replaced my semaphore (sem_t) with boost semaphore object, cpu utilization was much higher even while waiting on semaphore. I changed it back to my semaphore class and it solved the problem so issue is with boost semaphore.

Rohit Joshi — Wed, 11 Aug 2010 21:40:47 GMT

Forgot to mentioned that I use boost 1.43.0

Rohit Joshi — Tue, 17 Aug 2010 20:57:29 GMT

Any information on when would this fix be available?

milestone changed

Ion Gaztañaga — Tue, 24 Aug 2010 10:51:41 GMT

milestone Boost 1.44.0 → Boost-1.45.0

FreeBSD does not define _POSIX_SEMAPHORES so Interprocess was not using sem_xxx for named semaphores. However FreeBSD supports sem_xxx with some bugs:

http://www.freebsd.org/cgi/man.cgi?query=sem_open&apropos=0&sektion=0&manpath=FreeBSD+9-current&format=html

BUGS

This implementation places strict requirements on the value of name: it must begin with a slash (`/'), contain no other slash characters, and be less than 14 characters in length not including the terminating null character.

Interprocess for Boost 1.45 will use sem_xxx family if FreeBSD is detected.

Tue, 24 Aug 2010 19:25:46 GMT

It seems that man pages on freebsd site are outdated. This bugs have been fixed. http://svn.freebsd.org/viewvc/base?view=revision&revision=201884

status changed; resolution set

Ion Gaztañaga — Thu, 26 Aug 2010 10:24:55 GMT

status new → closed
resolution → fixed

Fixed for Boost 1.45 in release branch

status, version changed; resolution deleted

Sat, 02 Jul 2011 06:03:25 GMT

status closed → reopened
version Boost 1.44.0 → Boost 1.46.1
resolution fixed

Reproduced with boost-1.46.1 in FreeBSD-9 (the same system). The same problem with timed_wait().

version changed

Thu, 25 Aug 2011 16:36:00 GMT

version Boost 1.46.1 → Boost 1.47.0

At quick glance seems that freebsd does not define _POSIX_THREAD_PROCESS_SHARED, but defines _POSIX_SEMAPHORES, so BOOST_INTERPROCESS_POSIX_PROCESS_SHARED is not defined and BOOST_INTERPROCESS_POSIX_NAMED_SEMAPHORES is defined. At file interprocess_semaphore.hpp there is a check for both BOOST_INTERPROCESS_POSIX_PROCESS_SHARED and BOOST_INTERPROCESS_POSIX_NAMED_SEMAPHORES.

I'm not sure why BOOST_INTERPROCESS_POSIX_PROCESS_SHARED is checked for semaphores. After reading posix docs I think it is for interprocess mutexes and condvars, semaphores are process-shared by definition. Patch for boost 1.47 attached, it fixes bug for me (on freebsd).

attachment set

Thu, 25 Aug 2011 16:36:47 GMT

attachment → ipc_sem.patch

Patch for fixing bug

anonymous — Sun, 16 Dec 2012 15:33:13 GMT

#include <boost/interprocess/detail/workaround.hpp> #undef BOOST_INTERPROCESS_FORCE_GENERIC_EMULATION #include <boost/interprocess/sync/interprocess_semaphore.hpp>

int _tmain(int argc, _TCHAR* argv[]) {

interprocess_semaphore sem;

}

This code can work and cpu is normal, but build with runtime-link-static,it will detect memory leaks.

my system is vs2008 sp1.

status changed; resolution set

Ion Gaztañaga — Thu, 30 Jun 2016 20:18:29 GMT

status reopened → closed
resolution → fixed

Closing this old bug as current version (since Boost 1.55) uses efficient spinlocks with waits when the interprocess semaphore is emulated