interprocess::interprocess_semaphore consumes cpu while waiting

[Gennady Proskurin <gpr@…>]

If wait() blocks, thread which executes wait() on interprocess_semaphore consumes cpu (possibly in loop doing thread_yield)

[Gennady Proskurin <gprspb@…>]

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

[Gennady Proskurin <gprspb@…>]

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]

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]

Forgot to mentioned that I use boost 1.43.0

[Rohit Joshi]

Any information on when would this fix be available?

[Ion Gaztañaga]

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.

[Gennady Proskurin <gprspb@…>]

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

[Ion Gaztañaga]

Fixed for Boost 1.45 in release branch

[Gennady Proskurin <gprspb@…>]

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

[Gennady Proskurin <gpr@…>]

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).

[Gennady Proskurin <gpr@…>]

Patch for fixing bug

[anonymous]

#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.

[Ion Gaztañaga]

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