Thread-safe reference counts.

"Jon Harrop" <usenet@jdh30.plus.com> wrote in message
news:13uqrk9au723v0d@corp.supernews.com...
> jason.cipriani@gmail.com wrote: 
>
> A concurrent garbage collector is the appropriate way to handle that
> situation.

Why? There are many different ways to handle lifetime management.

Ian Collins wrote:
> Jon Harrop wrote: 
>
> One possible way, reference counted objects work just as well.

They are an order of magnitude slower and leak on cycles.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u

Jon Harrop wrote:
> Ian Collins wrote: 
>
> They are an order of magnitude slower and leak on cycles.
>
Nonsense, show us the data.

--
Ian Collins.

"Jon Harrop" <usenet@jdh30.plus.com> wrote in message
news:13ur7d6c6joov2d@corp.supernews.com...
> Ian Collins wrote: 
>
> They are an order of magnitude slower and leak on cycles.

What type of counting algorithm are you talking about? I know a certain type
of distributed reference counting can incur virtually zero-overheads. There
is also deferred counting, weighted counting, ect...

On 28 mar, 23:50, Ian Collins <ian-n...@hotmail.com> wrote:
> Jon Harrop wrote: 
 

> One possible way, reference counted objects work just as well.

That's wrong on two counts: first, reference counted objects
fail when cycles are present (which is almost always the case in
my code), and of course reference counting is more expensive in
terms of CPU time, especially in a multithreaded environment.
The latter is, of course, rarely a real problem.  The first,
however, pretty much means that there are cases where reference
counting can't be used.

If the problem is freeing memory, especially in a multithreaded
environment, using the Boehm collector with C++ is definitly the
simplest solution.  In his case, it sounds like
boost::shared_ptr would also be an effective solution.  The
additional runtime will probably not be noticeable, and from his
very general description, it doesn't should like there would be
cycles, or if there were, they should be easy to break.  (If
he's currently using neither, it's definitely easier to adopt
boost::shared_ptr---the Boehm collector requires some non
trivial configuration.  On the other hand, I find it worthwhile
to invest the effort, since the results are generally useful.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On 29 mar, 02:58, Ian Collins <ian-n...@hotmail.com> wrote:
> Jon Harrop wrote: 
e 
 

> Nonsense, show us the data.

Well, they obviously leak if cycles are present.  And while "an
order of magnitude slower" is obviously false as well, Hans
Boehm has performed a number of benchmarks, and they are slower
in a lot of cases.

A lot depends on how you use dynamic memory.  The runtime of a
typical collector depends on the amount of memory actually in
use when the garbage collector runs; the runtime of a typical
manual memory allocator depends on the number of allocations and
frees.  An application which uses a lot of small, short lived
objects, and disposes of adequate memory, will run significantly
faster with garbage collection.  An application which only
allocates a few, very big object, will run faster with manual
collection or shared pointers.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On 28 mar, 23:56, "Chris Thomasson" <cris...@comcast.net> wrote:
> "Jon Harrop" <use...@jdh30.plus.com> wrote in message

> news:13uqrk9au723v0d@corp.supernews.com...
 
 

> Why? There are many different ways to handle lifetime management.

Just to make it clear: the original posting talked about memory
management, not object lifetime management.  From the way it was
presented, it more or less sounded like object lifetime had no
significance (often the case).  In which case, garbage
collection is fine.  But garbage collection has nothing to do
with object lifetime (which, when significant, still must be
managed, garbage collection or not).

The original poster presented a very concrete problem, for which
garbage collection is probably the best solution, but for which
boost::shared_ptr would probably work almost as well.  If he's
already using one, but not the other, then the solution is
obvious.  If he's using both, I'd go with garbage collection:
less complexity and less actual coding.  If he's using neither,
it depends.  Boost::shared_ptr is definitly easier to introduce
into a project, but garbage collection is likely to have more
long term benefits.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

Ian Collins wrote:
> Jon Harrop wrote: 
>
> Nonsense, show us the data.

Read Jones and Lins "Garbage Collection" and references therein for a start.

Reference counting is very slow because updating reference counts requires
cache incoherent memory access, which is very slow on modern hardware and
is getting relatively slower every year as CPU speed increases faster than
memory speed. The slowdown is already enormous.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u

James Kanze wrote:
[...]
> That's wrong on two counts: first, reference counted objects
> fail when cycles are present (which is almost always the case in
> my code), ...

See

http://www.open-std.org/JTC1/SC22/W...297.html#cycles

regards,
alexander.

Jon Harrop wrote:
>
> Ian Collins wrote: 
>
> Read Jones and Lins "Garbage Collection" and references therein for a star
t.
>
> Reference counting is very slow because updating reference counts requires
> cache incoherent memory access, which is very slow on modern hardware and

"cache incoherent"? :-)

> is getting relatively slower every year as CPU speed increases faster than
> memory speed. The slowdown is already enormous.

You seem to presume heavy contention while copying and
modifying/destroying shared pointers (maintaining reference counts).

If that is the case, then running transaction in a separate address
space without any managed memory reclamation is surely best. No garbage
collection is needed. ;-)

regards,
alexander.