Modify

Opened 7 years ago

Closed 13 months ago

#4524 closed Bugs (fixed)

interprocess::interprocess_semaphore consumes cpu while waiting

Reported by: Gennady Proskurin <gpr@…> Owned by: Ion Gaztañaga
Milestone: Boost 1.45.0 Component: interprocess
Version: Boost 1.47.0 Severity: Problem
Keywords: Cc: gprspb@…

Description

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

Attachments (2)

sem.cc (289 bytes) - added by Gennady Proskurin <gprspb@…> 7 years ago.
When main thread sleeps in sleep(), thread thr1 does wait() on semaphore and consumes cpu while waiting.
ipc_sem.patch (624 bytes) - added by Gennady Proskurin <gpr@…> 6 years ago.
Patch for fixing bug

Download all attachments as: .zip

Change History (13)

Changed 7 years ago by Gennady Proskurin <gprspb@…>

Attachment: sem.cc added

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

comment:1 Changed 7 years ago by 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

comment:2 Changed 7 years ago by 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.

comment:3 Changed 7 years ago by Rohit Joshi

Forgot to mentioned that I use boost 1.43.0

comment:4 Changed 7 years ago by Rohit Joshi

Any information on when would this fix be available?

comment:5 Changed 7 years ago by Ion Gaztañaga

Milestone: Boost 1.44.0Boost-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.

comment:6 Changed 7 years ago by 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

comment:7 Changed 7 years ago by Ion Gaztañaga

Resolution: fixed
Status: newclosed

Fixed for Boost 1.45 in release branch

comment:8 Changed 6 years ago by Gennady Proskurin <gprspb@…>

Resolution: fixed
Status: closedreopened
Version: Boost 1.44.0Boost 1.46.1

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

comment:9 Changed 6 years ago by Gennady Proskurin <gpr@…>

Version: Boost 1.46.1Boost 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).

Changed 6 years ago by Gennady Proskurin <gpr@…>

Attachment: ipc_sem.patch added

Patch for fixing bug

comment:10 Changed 5 years ago by 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.

comment:11 Changed 13 months ago by Ion Gaztañaga

Resolution: fixed
Status: reopenedclosed

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

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.