develooper Front page | perl.perl6.internals | Postings from February 2001

Re: Garbage collection (was Re: JWZ on s/Java/Perl/)

Thread Previous | Thread Next
From:
Dan Sugalski
Date:
February 15, 2001 20:14
Subject:
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
Message ID:
5.0.2.1.0.20010215231119.01b06800@24.8.96.48
At 09:13 PM 2/15/2001 -0500, Ken Fox wrote:
>Hong Zhang wrote:
> > The memory barriers are always needed on SMP, whatever algorithm
> > we are using.
>
>I was just pointing out that barriers are an alternative to mutexes.
>Ref count certainly would use mutexes instead of barriers.

Not really they aren't. Barriers are an intrinsic part of most mutexes. 
POSIX ones at least, by definition. Pretty much everyone else's mutexes as 
well.

> > The memory barrier can be easily coded in assembly, or intrinsic
> > function, such as __MB() on Alpha.
>
>Perl ain't Java! We have to worry about XS code written in plain
>old scary C. If we see some really amazing performance improvements
>then I could imagine going with barriers, but I'm doubtful about
>their portability and fragility.

To some extent extensions are going to be on their own with respect to 
threads, and there's nothing we can do about that. (No matter how hard we 
try, we can't make Oracle's OCI interface do all our Weird Magic Stuff 
automatically) Writing threaded extension code shouldn't be that hard in 
the common case, so it'll be in our best interest to help, but there will 
be limits.

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About