[boost] Re: live_ptr (Was: Libraries requested orunderconstruction)

From: Csaba Szepesvari (szepes_at_[hidden])
Date: 1999-07-29 01:56:27

> I think that the gist of the answer is "We're using C++: if we wanted such
> protection we would use a language system that supports it directly;
> or, we would be using a proper GC system; or, we would have coded
> it up ourselves."

I knew that someone will come up with this argument:-)
However, my argument was that reference counting where you protect *only* the counter is not
multi-thread safe (contrary to the beliefs). The unsafe nature originates at the deallocation part and
it is exactly the automatic deallocation why you want to have a reference counting mechanism. Other
smart pointers can be (partially) protected and/or you can ask the client of the software to be nice,
too. But you cannot ask a client of a reference counting mechanism to be nice or the idea of automatic
deallocation becomes meaningless.

> The usual performance vs. safety issues apply. Multiple levels of thread safety:

.. Yes, true..

> I.e. given nearly any parallel programming model, I can show you a computer
> architecture that violates its atomicity assumptions. Like: do you think that
> aligned stores of 32 bit data quantities are atomic? The hardware goes to
> some effort to make them appear to be so, but I can show you a few
> plausible microarchitecture proposals that violate that rule. Unlikely to
> be implemented by Intel in the near future - *I* wrote the manual section
> promising that aligned 32 bit data stores in ordinary cacheable memory
> would be atomic - but attractive.

Ok, fair enough. However, I could argue that minimizing the likelihood of crashing the system and (what
is even more important) developing applications for the future (for architectures that will not violate
their atomicity assumptions?) are reasonable goals (the first is practical, the second being similar to
writing heavily templatized stuff that won't compile on most of the current compilers).

> >smart pointers are dangerous because people tend to think that they are safe.
>
> Valid point.
>
> >See comments above. I suggest to include a statement in the description of every piece of code if
> >it is multi-thread safe. And sometimes, occasionally think about multi-thread safe versions.
>
> Fair enough, except I suggest changing the default:
>
> Always assume that code is not multithread safe or exception safe unless proven otherwise
> (and, hopefully, tested - lots of "proofs" have more bugs than the code).
>
> And don't hang out for absolute multithread safety. Consider intermediate
> forms of multithread safety, such as the "multithread safe against everything
> but delete" moel I mentioned above.

Agreed.
How about some (simplified) threadsafety_traits.
Then e.g.
template <threadsafety_trait thread_safety>
void f( )
{
  if (thread_safety==threadsafety_trait::maximal)
 {
    // lock everything
 }
}
If thread_safety!=threadsafety_trait::maximal then any reasonable compiler should discard the locking
mechanism from the actual code (unfortunately, you would still need the headers that provide the
interface to the multi-threaded stuff, but probably this is a small price compared to duplicating your
code by providing both a thread-safe and a non thread-safe version.)

Another topic (I think I would stop the discussion relating the MT-safety issue):
Have anyone ever seen a real non-intrusive copy-on-write smart pointer? (this is a request, if you
like)
I know the implementation in the KSVH collection (http://www.xmission.com/~ksvhsoft/code/index.html),
but that is not I am thinking of.
The problem is that a compiler cannot tell if an access is for reading or writing (the const modifier
of methods refers to the type of this (the object) and not the operation. E.g. if you provide both a
const and non-const version of operator-> and operator* then the compiler will call the non-const
version for non-const smart pointers (which is usually the case), which will usually result in an
unnecessary copy of the pointee (if the pointee is requested in a non-modifying operation only).
So the usual suggestion is to use proxys but I see no way to implement generic proxys in a
non-intrusive way.

Thoughts?

- Csaba