Re: [boost] [thread|interprocess] Boost.Synchro: Towards a generic view of synchronization mechanisms

Subject: Re: [boost] [thread|interprocess] Boost.Synchro: Towards a generic view of synchronization mechanisms
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-02-06 14:31:21

----- Original Message ----- 
From: "Ion Gaztañaga" <igaztanaga_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, February 06, 2009 6:52 PM
Subject: Re: [boost] [thread|interprocess] Boost.Synchro: Towards a generic view of synchronization mechanisms

> 
> vicente.botet wrote:
>> Hi,
>> 
>> Currently there are two libraries defining mutex, condition variables and locks in Boost (Boost.Thread and Boost.Interprocess), which have similar interfaces but with some differences. This has as consequence that we can not interchange them.
> 
> Yes, it's a pity. However, the aim of Boost.Interprocess was to adopt 
> the standard C++ interface. At the time Interprocess was designed there 
> was not such interface and the interface Howard Hinnant proposed long 
> time ago.
> 
> I will surely, adapt them standard interface and deprecate 
> Boost.Interprocess locks (but maintain them for backwards compatibility) 
> so that all synchronization primitives can be reused, including future 
> lock algorithms.

This will be great but not completly necesary with the function approach. There is a difference that breaks more that the others, the exception thrown are different in both cases from the standard ones. This force to use a try-catch when the exceptions are not the standard ones.

Anyway, could you say when do you think this should be available? 
 
> Semaphores are different because they have different uses. If a 
> programmer wants to use a semaphore as a mutex, I think he should write 
> his own adapter, or in the future, write a concept_map.

I think that the function template approach is more open in the same way we have free functions e.g. begin() end() on  the range library. The partial specialization of the function templates is a kind of concept_map. Maybe I'm wrong but concept_maps will not be widely available too soon.

So if I understand you think that the partial specialization of the function templates approach is not the good approach in this case for the mid_term. Please let me know, your opinon count a lot to me.

Thanks,
Vicente