condition_variable and the internal mutex
Hi Boost, I was surprised to see an internal mutex added to boost::condition_variable implementation in the recent versions of Boost. Quick internet searched revealed that this was done to better support thread cancellation: http://permalink.gmane.org/gmane.comp.lib.boost.devel/210235 That thread ends with a suggestion to add back a zero-overhead pthread_cond_t wrapper and no reply. So I was wondering whether there plans to reinstate that wrapper or should Boost users that are not concerned with thread cancellation but are rather concerned with code performance drop using boost::condition_variable and resort to writing their own wrapper? -- Maxim
Le 25/09/12 16:26, Maxim Yegorushkin a écrit :
Hi Boost,
I was surprised to see an internal mutex added to boost::condition_variable implementation in the recent versions of Boost. Quick internet searched revealed that this was done to better support thread cancellation:
http://permalink.gmane.org/gmane.comp.lib.boost.devel/210235
That thread ends with a suggestion to add back a zero-overhead pthread_cond_t wrapper and no reply.
So I was wondering whether there plans to reinstate that wrapper or should Boost users that are not concerned with thread cancellation but are rather concerned with code performance drop using boost::condition_variable and resort to writing their own wrapper?
Hi, I've forgotten this old post. Please could you create a ticket? I would try to take care of it, but this will take some time. I would have the time to see also if I can implement cancelable threads on top of non-cancelable threads, but this has yet less priority. Best, Vicente
On 25/09/12 18:10, Vicente J. Botet Escriba wrote:
Le 25/09/12 16:26, Maxim Yegorushkin a écrit :
Hi Boost,
I was surprised to see an internal mutex added to boost::condition_variable implementation in the recent versions of Boost. Quick internet searched revealed that this was done to better support thread cancellation:
http://permalink.gmane.org/gmane.comp.lib.boost.devel/210235
That thread ends with a suggestion to add back a zero-overhead pthread_cond_t wrapper and no reply.
So I was wondering whether there plans to reinstate that wrapper or should Boost users that are not concerned with thread cancellation but are rather concerned with code performance drop using boost::condition_variable and resort to writing their own wrapper?
Hi,
I've forgotten this old post. Please could you create a ticket? I would try to take care of it, but this will take some time.
I would have the time to see also if I can implement cancelable threads on top of non-cancelable threads, but this has yet less priority.
Thanks for your prompt reply Vincente. https://svn.boost.org/trac/boost/ticket/7422 -- Maxim
participants (2)
-
Maxim Yegorushkin -
Vicente J. Botet Escriba