From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-09-24 06:53:02
Sid Sacek wrote:
> Hi Phil,
>
> I had a chance to think about this issue with spin-locks a bunch more.
>
> Okay, while I agree with you that the possibility of a thread being
> pre-empted in the middle of the assembly lock-routine is small, there is
> still that possibility that it will happen, and depending on the
> application, it might happen noticeably too often.
Some numbers would be nice :-)
> Knowing that, the programmer should be given the option whether to use ( or
> not use ) the spin-locking mechanism in their code. I'm certain that most
> applications will be fine using the locks in this manner, but there will be
> cases where the possibility of wasting CPU cycles will be unacceptable. This
> will all depend on the application and how often locking is performed in
> that program.
I tend to disagree concerning the atomics used for shared pointers, but
in the more general case of mutex implementations I do agree that
offering the user two or more implementations would be useful. I
wonder how this would fit in with the recently-proposed std::threads
work? This needs investigation.
> I know that I personally would want the option of being able to turn that
> feature on and off at my discretion, and I'm sure that others would too.
Note that sp_counted_base.hpp has some preprocessor stuff to select an
implementation, and I believe that you can influence this with suitable
#defines; so if you wanted to use pthreads mutexes (i.e. to get the
current behaviour) then you could get that. The only proviso is that
all code compiled together would need to use the same (or compatible) implementations.
> If you make it so that ARM coders are forced to always use the spin-locks,
Oh come off it. I'm not in a position to "force" anyone to do
anything. The chances of the code that I posted ever being included in
Boost are tiny - just look at how few replies there have been to this
thread. And Boost doesn't have any ARM-based testing systems and ARM
isn't even a supported platform, so there would be justified objections
to ever including the code. The only people who will ever use this
stuff are people who try the default Boost shared pointers, find that
they are very slow, find my implementation [either the original version
with pure spin-locks or the one I posted in the last message that
yields] and _choose_ to use it.
> they may then be forced into not using the boost::shared_ptrs and come up
> with their own implementations.
What does the code that I posted in my last email not do that you need?
> If I had a say in this matter, I would request that the underlying locking
> mechanism be configurable.
You do have a say, Boost is a democracy.
Thanks for your interest.
Regards,
Phil.