Re: [boost] Shared pointer atomic assembler for ARM?

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.