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.