[boost] Re: llinked_ptr in the vault

From: Borgerding, Mark A. (MarkAB_at_[hidden])
Date: 2000-03-03 17:46:30

> -----Original Message-----
> From: Miki Jovanovic [mailto:miki_at_[hidden]]
> Sent: Friday, March 03, 2000 5:01 PM
[snip]
> 
> In this example, ptr1 will have the value of ptr3, but will be in the
> linked list for ptr2. Big problem. You have a reference count out of
> sync, and can cause the object pointed to by ptr1 to be deleted while
> ptr1 still points to it.

Not to make light of the problem, but that still falls into the catch-all
category of undefined behavior.

I wanted to make linked_ptr safe to *access* from multiple threads.  Your
example *changes* an object in multiple threads.
I think that calling an object's non-constant functions in multiple threads
is an invitation to chaos.
Especially when the behavior of that object is meant to emulate a primitive.

SGI tends to agree with this approach.
http://www.sgi.com/Technology/STL/thread_safety.html states the case much
better than I could.

> 
> > > - Sorry for not compiling your code, but will it compile with a
> static
> > > variable declaration without the corresponding .cpp file 
> where it is
> > > defined?
> > 
> > It is declared static (and defined) within the scope of the 
> function.
>  As
> > long as that function does not somehow end up with multiple
> definitions, I
> > think it should be okay.
> 
> I always get confused with compilation units... Header file is not a
> compilation unit, it has to be included. Static variables have to be
> defined in a compilation unit, no matter where the 
> declaration lies. If
> included in several .cpp's how does linker know which one... Very
> confusing. I'll just have to trust you on this one :-)
> 

I admit I am fuzzy on the details of the linkage of a static variable within
a function that is defined in multiple translation units. I'm not sure what
standard behavior is.  Using MSVC, I've included the header file into
different cpps and only one definition of the function is generated.

Hmm, this does seem to be treading on thin ice, tho.  It is probably best to
move this into an implementation file and take the performance hit for the
function calls.

Thoughts?

- Mark