Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Thread-safe reference counts.

Reply
Thread Tools

Thread-safe reference counts.

 
 
Dmitriy V'jukov
Guest
Posts: n/a
 
      04-04-2008
On Apr 4, 10:44 am, "Chris Thomasson" <(E-Mail Removed)> wrote:

> > My point is that this whole issue has been turned on its head in the
> > name of premature optimization.

>
> strong thread-safety is a _requirement_ for several different algorithms,
> NOT an optimization.



David Schwartz asserts that basic thread safety is just an
optimization of strong thread safety - just make *all* smart pointer
strongly thread-safe, and forgot about basic thread-safety. If I
understand him correctly.


Dmitriy V'jukov
 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      04-04-2008
On Apr 4, 8:05 am, "Chris Thomasson" <(E-Mail Removed)> wrote:
> "James Kanze" <(E-Mail Removed)> wrote in message


[...]
> > That feedback from the
> > garbage collector can help in such low level optimization, I
> > have no doubt, but I tend to view such things as happening "under
> > the hood" for the application level programmer; he just sees his
> > design object.


> My only point was that, IMHO, GC can help out with certain
> types of lifetime management schemes because it can detect
> when an object can be "safely" destroyed. That can be a fairly
> important piece of information.


Yes. For a specific definition of "object lifetime". When I
speak of object lifetime, I'm normally thinking of the OO design
concept. I agree that with a more generalized definition, if
you're thinking in terms of object as a lower level concept (a
bit of memory containing a value---i.e. like the definition of
the word in the C and C++ standards), then there's a sense in
which garbage collection integrates, or can or should integrate
with object lifetime. Thus, my safety feature, of having the
terminated object mark that it is terminated, and verify on each
use that it isn't so marked, depends on the lifetime of the
underlying memory (the low level object) lasting as long as
there are any pointers to it; the lifetime of the OO object is
not the same as that of the physical (for lack of a better word)
object.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
 
 
 
Gil Hamilton
Guest
Posts: n/a
 
      04-04-2008
"Dmitriy V'jukov" <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> On Apr 4, 10:44 am, "Chris Thomasson" <(E-Mail Removed)> wrote:
>
>> > My point is that this whole issue has been turned on its head in
>> > the name of premature optimization.

>>
>> strong thread-safety is a _requirement_ for several different
>> algorithms, NOT an optimization.

>
>
> David Schwartz asserts that basic thread safety is just an
> optimization of strong thread safety - just make *all* smart pointer
> strongly thread-safe, and forgot about basic thread-safety. If I
> understand him correctly.


Yes. You and Chris keep trying to make a distinction between "strong
thread safety" and "ordinary thread safety". However, it sounds to me (and
I believe this is David's point as well) that what you are defining as
"ordinary thread safety" is NOT thread-safe at all. If it isn't safe to
use among multiple threads then how can it be called thread-safe?

Now, assuming that you have some "ordinary thread safety" that actually IS
thread-safe, then you would have no need for any notion of *strong* thread
safety because your "ordinary" thread safety already has all the properties
of the "strong" version.

GH
 
Reply With Quote
 
Dilip
Guest
Posts: n/a
 
      04-04-2008
On Apr 4, 7:06 am, Jon Harrop <(E-Mail Removed)> wrote:
> Chris Thomasson wrote:
> > "Jon Harrop" <(E-Mail Removed)> wrote in message
> >news:lO6dnXF0D5GM-GjanZ2dnUVZ8u2dnZ2d@plusnet...
> >> Dilip wrote:
> >>> On Mar 30, 10:48 pm, Jon Harrop <(E-Mail Removed)> wrote:
> >>>> Chris Thomasson wrote:
> >>>> > Some reference counting algorithms are 100% accurate in that an
> >>>> > object is IMMEDIATELY destroyed when its count drops to zero.

>
> >>>> A 100% accurate collector will collect a value as soon as it is
> >>>> unreachable. Reference counting does not do that.

>
> >>> Unreachability is determined only _after_ the GC is triggered.

>
> >> No, unreachability is a theoretical property that is well defined at all
> >> times regardless of when the GC is triggered or even whether or not a GC
> >> exists.

>
> > The GC can only determine if an object is unreachable AFTER it runs some
> > collection cycles! GOT IT!?

>
> Correct but irrelevant. I was not referring to the properties of a GC but,
> rather, to the properties of the heap during run-time.
>
> >>> Reference counting on the other hand, barring cycles,
> >>> can destroy that object _immediately_ after the count reaches zero.

>
> >> The value can be unreachable before the count reaches zero.

>
> > WRONG! WRONG! WRONG! WRONG! ROFL!

>
> > There are reference(s) to the object which is keeping the count above
> > zero. Therefore the object __IS__ reachable.

>
> In the example I gave:
>
> {
> Bar bar;
> f(bar);
> // *
> g();
> }
>
> At * there are zero references to "bar" but its reference count is one.


So what? In a GC-scenario bar might be unreachable at * if its a
reference type -- ok Good. that doesn't mean its about to be
collected. so in the ref-counting case, bar is alive till the end of
scope, in the GC case bar is alive until a GC can be triggered. in
both cases its just sitting there twiddling its thumbs. you are just
making a distinction without difference.

> Incidentally, the need to update reference counts whilst unwinding the stack
> as an exception propagates is another performance cost not present in
> modern alternatives. For example, exceptions are ~6x faster in OCaml than
> C++ (with g++).


Why are we suddenly talking about exceptions?
 
Reply With Quote
 
Gil Hamilton
Guest
Posts: n/a
 
      04-04-2008
"Chris Thomasson" <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> "Gil Hamilton" <(E-Mail Removed)> wrote in message
> news:Xns9A768FA2CB441gilhamiltonhotmailco@194.177. 96.78...
>> "Dmitriy V'jukov" <(E-Mail Removed)> wrote in
>> news:(E-Mail Removed)


>> Yes. You and Chris keep trying to make a distinction between "strong
>> thread safety" and "ordinary thread safety". However, it sounds to me
>> (and I believe this is David's point as well) that what you are
>> defining as "ordinary thread safety" is NOT thread-safe at all.

>
> shared_ptr honors the ordinary/basic thread-safety level.


OK. I think we're all violently agreeing except perhaps as to terminology.
If we are discussing "thread-safe accesses and manipulations of reference-
counted objects", which seems to have been the chief topic of this thread,
then certainly shared_ptr does not begin to provide that. And hence, for
the purposes of this discussion -- IMO -- it cannot be considered thread-
safe in any sense.

GH
 
Reply With Quote
 
Peter
Guest
Posts: n/a
 
      04-04-2008
On Mar 26, 5:50*pm, "(E-Mail Removed)"
<(E-Mail Removed)> wrote:
> The problem is in Release(). There is a short period of time where the
> mutex is unlocked but the object is already doomed for destruction; if
> another thread calls AddRef() during that time, that other thread now
> has a pointer to garbage and doesn't know it.



I guess you have somewhere a weak pointer (in contrary to a hard
reference counted pointer)
which is going to be destroyed by the destructor of the object, am I
right?
E.g. you have some object factory which contains pointers to all
created objects in a map.
In this case you need to lock this map when calling AddRef() or
Release().
And of course looking up an entry in this map must also be locked.


 
Reply With Quote
 
David Schwartz
Guest
Posts: n/a
 
      04-04-2008
On Apr 3, 11:40 pm, "Chris Thomasson" <(E-Mail Removed)> wrote:

> The quick answer is to use external locks. Solving this with locks is
> trivial. So, how would you do it without using locks? Think about this for a
> moment. thread_a cannot use 'refcount_acquire' because it could run into the
> following race-condition:


Your question is nonsensical. A perfectly good answer to the
nonsensical question is "I would use ATOMIC_MAGIC(g_shared)" which
somehow makes it all work.

You get to invent magic ATOMIC operations that make everything work
and then say all I have are locks. Then you say I can't use locks?!
Wtf?

> That is the race-condition which basic thread-safety simply cannot
> address... Also, read this post:


That's why "basic thread-safety" is an optimization to be used when
appropriate and when there is proven need for such optimization. It is
like a car that cannot be driven at 3AM on Thursdays. A car should
work any time, and one that doesn't work in unusual but perfectly
reasonable situations should be used only in the exceptional case
where the benefits are known to outweigh the costs".

DS
 
Reply With Quote
 
Thomas J. Gritzan
Guest
Posts: n/a
 
      04-10-2008
Jon Harrop wrote:
> Chris Thomasson wrote:
>> "Jon Harrop" <(E-Mail Removed)> wrote in message
>> news:VaWdnUKR2Pn7SmDanZ2dneKdnZydnZ2d@plusnet...
>>> Just Google for:
>>>
>>> +"linus torvalds" +"garbage collection"
>>>
>>> and you will find a multitude of uninformed statements made by Linus on
>>> the subject of garbage collection.

>> I guess you don't use Linux.

>
> We do use Linux but I'm not about to take Linus' advice about garbage
> collection because he is a project coordinator for part of one of the OSs
> we use.
>
>> How much experience with creating widely popular operating systems do you
>> have?

>
> Irrelevant. This was about garbage collection.


Irrelevant. This was about GC in kernel mode.

>>> Here is another quote:
>>>
>>> "repeat after me: "garbage collection is stupid, slow, bad for caches,
>>> and
>>> only for people who cannot count""
>>>
>>> Just look at the qualifications among OCaml and Haskell users. Do you
>>> really
>>> believe they "cannot count"? Our expertise is in high-performance
>>> scientific computing. We know that the vast majority of technical users
>>> now choose garbage collected languages. Do you really believe
>>> they "cannot count" as well?


Tell us an OS thats written in OCaml or Haskell, or even uses GC in kernel
mode.
The quote was in context of OS kernel mode code. Not even Microsoft did that.

>> Your not going to be creating a very popular OS anytime soon.

>
> You realise Linux isn't "very popular" by any stretch of the imagination?


Huh?

fup2: c.p.t

--
Thomas
http://www.netmeister.org/news/learn2quote.html
"Some folks are wise, and some otherwise."
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ASP.NET 2.0: master pages and web user controls: reference to a non-shared member requires an object reference bminder ASP .Net 0 06-24-2005 12:22 AM
asp.net 2005 question re: "reference to a non-shared member requires an object reference" ce ASP .Net 1 06-23-2005 09:15 PM
web reference interfering with reference to component Dude ASP .Net 0 11-09-2004 11:53 AM
How to tell if a reference is project or file reference from within the IDE? Darren ASP .Net 0 10-11-2004 12:51 AM
Passing the value by reference is same as pointer by reference sam pal C++ 3 07-16-2003 09:14 PM



Advertisments