By: Patrick Chase (patrickjchase.delete@this.gmail.com), December 9, 2014 4:52 pm
Room: Moderated Discussions
David W (david.delete@this.wragg.org) on December 8, 2014 11:36 pm wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on December 5, 2014 12:58 pm wrote:
> > The problem with reference counts is that you often need to take
> > them *before* you take the lock that protects the object data.
> >
> > The thing is, you have two different cases:
> >
> > - object *reference*
> >
> > - object data
> >
> > and they have completely different locking.
>
> This is certainly true in multithreaded C/C++ code.
>
> In languages with automatic GC (e.g. anything based on the JVM), the question of object
> reference locking goes away: If a thread holds an object reference, it knows it can
> safely dereference it at any time. So in my experience, although concurrent programming
> with a GC is still hard, it is much less hard than concurrent programming without a GC.
You do realize that all you've done here is to move the problem, right? All of the arguments that Linus made still apply, they've simply been moved to the VM/GC.
> Of course, there is no free lunch:
Indeed.
> if you want your multithreaded GC-reliant program to scale, you need a scalable GC.
Which brings us right back to Linus' argument, more or less.
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on December 5, 2014 12:58 pm wrote:
> > The problem with reference counts is that you often need to take
> > them *before* you take the lock that protects the object data.
> >
> > The thing is, you have two different cases:
> >
> > - object *reference*
> >
> > - object data
> >
> > and they have completely different locking.
>
> This is certainly true in multithreaded C/C++ code.
>
> In languages with automatic GC (e.g. anything based on the JVM), the question of object
> reference locking goes away: If a thread holds an object reference, it knows it can
> safely dereference it at any time. So in my experience, although concurrent programming
> with a GC is still hard, it is much less hard than concurrent programming without a GC.
You do realize that all you've done here is to move the problem, right? All of the arguments that Linus made still apply, they've simply been moved to the VM/GC.
> Of course, there is no free lunch:
Indeed.
> if you want your multithreaded GC-reliant program to scale, you need a scalable GC.
Which brings us right back to Linus' argument, more or less.