MPProcessing in Lion

  • This past weekend I tried compiling my Snow Leopard Cocoa app in Lion (Xcode 4.3) just to make sure all was OK.  I got two warnings stating that MPProcessorsScheduled and MPCreateCriticalRegion were deprecated in Lion but the relevant Lion docs did not say what they should to be replaced with.

    I use MPProcessorsScheduled to create an equal number of parallel threads (for a long computation) and MPCreateCriticalRegion to serialize the core of a pseudo-random-number generator.

    Two questions:

      1.  What should I replace these with?
      2.  Will that replacement also work in Snow Leopard and, if not, what if-criterion should I use to make the code work in both places?

    Thanks very much for any help.

    --
    Michael P. McLaughlin
  • Le 14 mai 2012 à 14:34, McLaughlin, Michael P. a écrit :

    > This past weekend I tried compiling my Snow Leopard Cocoa app in Lion (Xcode 4.3) just to make sure all was OK.  I got two warnings stating that MPProcessorsScheduled and MPCreateCriticalRegion were deprecated in Lion but the relevant Lion docs did not say what they should to be replaced with.
    >
    > I use MPProcessorsScheduled to create an equal number of parallel threads (for a long computation) and MPCreateCriticalRegion to serialize the core of a pseudo-random-number generator.
    >
    > Two questions:
    >
    > 1.  What should I replace these with?
    > 2.  Will that replacement also work in Snow Leopard and, if not, what if-criterion should I use to make the code work in both places?
    >
    > Thanks very much for any help.
    >
    > --
    > Michael P. McLaughlin

    MPProcessorsScheduled() should not be used at all, and you should simply run your task using libdispatch (that is available on 10.6) and let it taking care of the number of thread to create.
    You can also use NSOperationQueue which is a high level wrapper on libdispatch.

    If you really want to now the count of processor, you can use [NSProcessInfo activeProcessorCount] method or sysctl("hw.activecpu").

    Critical section should be replaced by pthread mutex (that are available from OS X 10.0), or NSLock, or any other locking primitive.

    -- Jean-Daniel
  • On May 14, 2012, at 5:34 AM, McLaughlin, Michael P. wrote:

    > This past weekend I tried compiling my Snow Leopard Cocoa app in Lion (Xcode 4.3) just to make sure all was OK.  I got two warnings stating that MPProcessorsScheduled and MPCreateCriticalRegion were deprecated in Lion but the relevant Lion docs did not say what they should to be replaced with.
    >
    > I use MPProcessorsScheduled to create an equal number of parallel threads (for a long computation) and MPCreateCriticalRegion to serialize the core of a pseudo-random-number generator.
    >
    > Two questions:
    >
    > 1.  What should I replace these with?
    > 2.  Will that replacement also work in Snow Leopard and, if not, what if-criterion should I use to make the code work in both places?
    >
    > Thanks very much for any help.

    Read up on Grand Central Dispatch.  It can manage pretty much all of the hard work of parallelizing code, including replacing synchronization primitives like Mutexes and CriticalRegions (just access those sections on a single GCD queue with dispatch_sync, and you're guaranteed synchronous access).

    --
    Glenn L. Austin, Computer Wizard and Race Car Driver        <><
    "Where there's breath, there's hope!"
    <http://www.austin-soft.com>
  • On May 14, 2012, at 8:52 AM, Glenn L. Austin wrote:

    > Read up on Grand Central Dispatch.  It can manage pretty much all of the hard work of parallelizing code, including replacing synchronization primitives like Mutexes and CriticalRegions (just access those sections on a single GCD queue with dispatch_sync, and you're guaranteed synchronous access).

    For "single GCD queue", you should have said "single *serial* GCD queue".  And you don't have to use dispatch_sync() to get synchronization among the tasks queue to a serial queue.  You can use dispatch_async().  The difference between the two is whether the completion of the queued task is synchronous with the *caller*, not with each other.  And, if at all possible, you should design your code to not need to use dispatch_sync().

    Regards,
    Ken
  • On May 14, 2012, at 8:43 AM, Ken Thomases wrote:

    > On May 14, 2012, at 8:52 AM, Glenn L. Austin wrote:
    >
    >> Read up on Grand Central Dispatch.  It can manage pretty much all of the hard work of parallelizing code, including replacing synchronization primitives like Mutexes and CriticalRegions (just access those sections on a single GCD queue with dispatch_sync, and you're guaranteed synchronous access).
    >
    > For "single GCD queue", you should have said "single *serial* GCD queue".  And you don't have to use dispatch_sync() to get synchronization among the tasks queue to a serial queue.  You can use dispatch_async().  The difference between the two is whether the completion of the queued task is synchronous with the *caller*, not with each other.  And, if at all possible, you should design your code to not need to use dispatch_sync().

    True, and thanks for the clarification and correction.

    I blame lack of caffeine on my mis-statements.

    --
    Glenn L. Austin, Computer Wizard and Race Car Driver        <><
    "Where there's breath, there's hope!"
    <http://www.austin-soft.com>
previous month may 2012 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today