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
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
