[Insight-developers] Mac Semaphores (Was: Failing tests and compile errors after your check in)

[Bradley Lowekamp]

The other interesting thing I have just learning is the difference between ITK's FastMutexLock and the regular MutexLock. Apparently, it's not clear if our synchronization classes are between processes or between threads. The regular MutexLock is a slower IPC on windows.

I think we need to take this time to clear up ITKs threading model!

The itk::MutexLock should be a fast lock for threads not processes. What does everyone thing of removing of the inter process capabilities of these classes in favor of fast thread implementations?

Brad

On Feb 18, 2011, at 2:58 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote:

> I still question if we need itk::Semaphore. If it's only used in one class in all of ITK is it worth keeping and maintaining it for the next 10 years? 
> 
> I am implementing the semaphore in ParallelSparseFieldLS with a conditional variable now.
> 
> Brad
> 
> On Feb 18, 2011, at 2:48 PM, Daniel Blezek wrote:
> 
>> Hi Sean,
>> 
>>  The link below was very informative.
>> 
>>  But, that leaves us with some unanswered questions, namely, how do we
>> support semaphore-like functionality properly?
>> 
>>  I fixed the race condition via mutex, and an incrementing variable.
>> 
>> http://review.source.kitware.com/#change,990
>> 
>> -dan
>> 
>> 
>> On 2/18/11 12:49 PM, "Sean McBride" <sean at rogue-research.com> wrote:
>> 
>>> On Fri, 18 Feb 2011 11:59:07 -0600, Daniel Blezek said:
>>> 
>>>> POSIX semaphores are not fully supported on the Mac.
>>> 
>>> Mac OS X complies with POSIX 1003.1 and UNIX03.  The sem* functions are
>>> optional according to that standard.  A pity they didn't implement them. :(
>>> 
>>>> I don't know why this
>>>> works in the 64-bit version...
>>>> 
>>>> We are using sem_destroy to destroy our semaphores.  On the 32-bit Mac, I
>>>> get this return value (perror()):
>>>> 
>>>> 536: sem_destroy: Function not implemented
>>>> 
>>>> Why this linked and run, I'll never know...  Looks like I need to add some
>>>> APPLE specific code.  I suspect this will fix the problem on the Sun.
>>> 
>>> Apparently the standard at one point required failing stub functions,
>>> which is presumably why it links & runs.
>>> 
>>> The correct test for the sem functions is:
>>> 
>>> #if _POSIX_SEMAPHORES && (_POSIX_SEMAPHORES - 200112L) >= 0
>>> 
>>> See here for more:
>>> <http://lists.apple.com/archives/unix-porting/2009/May/msg00004.html>
>>> 
>>> An alternative is to use System V semaphores: semget().
>>> 
>>>> We also have a race-condition in our Semaphore code.  On the Mac, the
>>>> semaphores need unique names.  We generate this using the time() function,
>>>> but it has a one second resolution.  Thus if two semaphores are created
>>>> within 1 second, they will collide.  Not very nice.
>>> 
>>> mach_absolute_time() gives the best precision, but it's not portable.
>>> Or maybe use uuid_generate()?
>>> 
>>> --
>>> ____________________________________________________________
>>> Sean McBride, B. Eng                 sean at rogue-research.com
>>> Rogue Research                        www.rogue-research.com
>>> Mac Software Developer              Montréal, Québec, Canada
>>> 
>>> 
>> 
>> -- 
>> Daniel Blezek, PhD
>> Medical Imaging Informatics Innovation Center
>> 
>> P 127 or (77) 8 8886
>> T 507 538 8886
>> E blezek.daniel at mayo.edu
>> 
>> Mayo Clinic
>> 200 First St. S.W.
>> Harwick SL-44
>> Rochester, MN 55905
>> mayoclinic.org
>> "It is more complicated than you think." -- RFC 1925
>> 
> 
> ========================================================
> Bradley Lowekamp  
> Lockheed Martin Contractor for
> Office of High Performance Computing and Communications
> National Library of Medicine 
> blowekamp at mail.nih.gov
> 
> 
> <ATT00001..txt>

========================================================
Bradley Lowekamp  
Lockheed Martin Contractor for
Office of High Performance Computing and Communications
National Library of Medicine 
blowekamp at mail.nih.gov


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110218/5a8a373c/attachment.htm>