Opened 11 years ago

Closed 11 years ago

Last modified 6 years ago

#6108 closed Bugs (wontfix)

Boost interprocess lock consumes 100% CPU on OS X

Reported by: tibdewal.rahulkumar@… Owned by: Ion Gaztañaga
Milestone: To Be Determined Component: interprocess
Version: Boost 1.47.0 Severity: Showstopper
Keywords: Cc: viboes

Description

I have some code which waits for write operation on Shared Memory. If no one writes it continues to wait.

    Test* Foo::Get() 
    {
        boost::interprocess::scoped_lock<boost::interprocess::interprocess_mutex> lock ( mutex ) ; // mutex is boost::interprocess::interprocess_mutex
        if ( this->check == 0 )
            this->interprocessCondition.wait ( lock ) ; // interprocessCondition is boost::interprocess::interprocess_condition

...
    }

CPU consumption is 100%.

Debugging leads to inline void sched_yield(), for windows it calls Sleep(1) but I cannot find any definition for Mac.

I believe we need sched_yield() implementation and may be usleep(1000) within it.

Change History (18)

comment:1 by Ion Gaztañaga, 11 years ago

Resolution: wontfix
Status: newclosed

OS X is unix-like and calls POSIX function sched_yield(). CPU consumption is high if there are no other threads in the system (this is the best we can do). I don't think this is a bug, as sleeping for some time will hurt performance of other implementations with short lock times.

comment:2 by dummymail000@…, 10 years ago

I'm affected by this too. I didn't noted this when starting development. It consumes all the CPU. I'm building a kind of server through shared memory, and the server needs to keep waiting for a message indefinitely. It waits on a condition variable, but then, I noted my fans running high. Can't deploy this thing.

comment:3 by bledo, 10 years ago

(best we can do?) while I agree that sleeping will kill performance, running at 100% CPU will kill battery life on any laptop. Been locking one of the most basic functions, I can't believe you don't think this is a bug. I hope you reconsider. For the moment, boost is a no-no for macOs.

comment:4 by anonymous, 9 years ago

+1 buggy.

comment:5 by samuel@…, 9 years ago

On 10.8, simply adding:

#define BOOST_INTERPROCESS_POSIX_PROCESS_SHARED

Fixes the problem.

comment:6 by Ion Gaztañaga, 9 years ago

BOOST_INTERPROCESS_POSIX_PROCESS_SHARED is not fixing anything as Mac Os does not support POSIX process-shared synchronization primitives.

Starting in [85401] revision, all synchronization primitives based on spinlocks (for systems like Windows or Mac Os that don't support native process-shared synchronization primitives placed in shared memory) use an improved wait strategy, starting with a raw loop+yields for a OS tick (typically 10ms) and going to sleep after that. It has improved the performance and in most cases and CPU usage is very low.

comment:7 by anonymous, 9 years ago

igaztanaga, on 10.8, it appears that Mac is now supporting posix shared memory constructs for synchronisation. Perhaps you should check it.

comment:8 by Ion Gaztañaga, 9 years ago

Mac OS defines in unistd.h _POSIX_THREAD_PROCESS_SHARED but the function "pthread_mutexattr_setpshared" is not available according to:

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/index.html#

And even some other similar functions' man page

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/pthread_rwlockattr_setpshared.3.html

says: BUGS The PTHREAD_PROCESS_SHARED attribute is not supported.

Can you show me any page that shows that 10.8 has real support for THREAD_PROCESS_SHARED?

comment:9 by anonymous, 9 years ago

I found in the 10.8 SDK:

usr/include/pthread.h:int pthread_mutexattr_setpshared(pthread_mutexattr_t *, int );

But whether or not it is actually available is another question.

That man page is from 1998, has it actually been updated?

I can't give you a really good detail right now, but I DID have good success by manually defining

#define BOOST_INTERPROCESS_POSIX_PROCESS_SHARED

in my project, CPU usage went down significantly (basically to 0) and everything was working, as expected.

comment:10 by anonymous, 9 years ago

Okay, so I just ran a test case, got a positive result on 10.8.4

http://codeshare.io/ULnXr

It DOES appear to be working correctly.

Let me know if you'd like me to test some other APIs.

comment:11 by Ion Gaztañaga, 9 years ago

Thanks for the test. I've found reports on the net that shows that Mac Os 10.6 does not support it:

https://git.reviewboard.kde.org/r/102145/diff/?expand=1 http://alesteska.blogspot.com.es/2012/08/pthreadprocessshared-not-supported-on.html

I'm glad version 10.8 supports it. I can't find a definitive information about version 10.7 yet, but I've found this suggesting "pthread_mutexattr_setpshared" is supported (but we don't know if it returns EINVAL ;-) )

https://gist.github.com/2bits/2720855

If anyone can run your test in Mac Os 10.7 it would be very nice and I could try to activate pthread process-shared mutexes for 10.7 and newer versions.

comment:12 by viboes, 9 years ago

I don't reach to get the test. Ion, coul dyou add it to the regression test so that I can run it explicitly?

comment:13 by viboes, 9 years ago

Cc: viboes added

comment:14 by Ion Gaztañaga, 9 years ago

Vicente confirmed Mac Os 10.7 also passes your testcase successfully. I think the correct solution would be to detect the minimum Mac Os requirements for the build, checking the value of MAC_OS_X_VERSION_MIN_REQUIRED. Something like:

#if defined(__APPLE__)
 #include "TargetConditionals.h"
 //Check we're on Mac OS target
 #if defined(TARGET_OS_MAC)
        #include "AvailabilityMacros.h"
        //If minimum target for this compilation is older than Mac Os Lion, then we are out of luck
        #if MAC_OS_X_VERSION_MIN_REQUIRED < 1070
           #define BOOST_INTERPROCESS_BUGGY_POSIX_PROCESS_SHARED
        #endif
 #endif
#endif

If the SDK targets for Mac Os Lion or newer, then native process-shared mutexes will be available.

comment:15 by Ion Gaztañaga, 9 years ago

(In [85685]) Detect Mac Os version and allow process-shared synchronization primitives when minimum target is Mac Os Lion or newer (refs #6108).

comment:16 by anonymous, 6 years ago

This ticket is helpful thanks.

comment:17 by anonymous, 6 years ago

Employees tracking developing issue losing time-on the Web during work-hours is becoming this type of typical software problem facing supervisors and business people the phrase continues to be created to explain it.Some reports claim that U.S. employees invest around 20% or even more of each and every workday performing duties that are individual about the Internet.

Evidently, many people is going to do almost anything to prevent function, including bank buying and spending expenses, studying climate reviews and regional information, speaking with friends and family through social networking sites.Contemplating all of the cravings offered from the Web, it is no surprise that is becoming this type of problem for management.

comment:18 by mazhar, 6 years ago

As per Vicente confirmation Mac Os 10.7 also passed this testcase successfully. Me too feel the correct solution would be to detect the minimum Mac Os requirements for the build, checking the value of MAC_OS_X_VERSION_MIN_REQUIRED.

I'm happy that version 10.8 supports it now. I can't find exact info about version 10.7 yet, but I've found this suggesting "pthread_mutexattr_setpshared" is supported. If you found more on this please let me know if you want icici london swift code see it here.

I have also found it useful to manually define something like this

#define BOOST_INTERPROCESS_POSIX_PROCESS_SHARED

I got it from 10.8 SDK sr/include/pthread.h:int pthread_mutexattr_setpshared(pthread_mutexattr_t *, int ); but I am wondering if I can customize it to use it for my code.

Note: See TracTickets for help on using tickets.