At 10:57 PM 9/4/00 -0400, Chaim Frenkel wrote:
> >>>>> "SWM" == Steven W McDougall <[EMAIL PROTECTED]> writes:
>PRL> All threads share the same global variables
> >>
> >> _All_ or only as requested by the user (ala :shared)?
>
>SWM> All.
>
>Dan has gone through this with perl5 and he really would rather not
>have to go through that. He would like the amount of data that needs
>protection reduced.
I don't mind if package variables are all shared by default, or if there's
a simple way to share them all at thread creation time. We do tell people
to not use package variables so if access to them is slow, well, no biggie.
>You are also creating problems when I don't want mediation. What if
>I know better than perl and I want to us a single item to protect
>a critical section?
I'd definitely rather perl not do any sort of explicit user-level locking.
That's not our job, and there be dragons.
>SWM> Data coherence just means that the interpreter won't crash or corrupt
>SWM> its internal data representation. RFC178 uses the term *data
>SWM> synchronization* for coordinating access to multiple variables between
>SWM> threads.
>
>Then this RFC seems to be confusing two things. This is for -internals
>we don't even have any internal structures, so how can you be protecting
>them. If you are working at the language level this is the wrong forum.
Perl will guarantee coherence for any internal data structure that's shared
between threads. No core dumps because lock()'s not thread-safe here...
> >> Perhaps, I'm archaic, but I really wouldn't mind if the thread model
> >> basically copied the fork() model and required those variable that have
> >> to live across threads to be marked as :shared.
>
>SWM> Sigh...if that's the best I can get, I'll take it.
>
>I'm not the decisor here, I'm just pointing out another way to look
>at the problem. I really don't think you want to have _all_ variable
>actually visible. Even if they were, you will most likely have only
>a limited number that you want visible.
Reducing the number of visible items is good, because it means perl doesn't
have to keep its internal locks on thread-specific data elements. Perl can,
to some extent, intuit which items aren't visible and skip making them
shared, but that requires what's likely to be rather expensive flow
analysis. (Which we might do anyway, sort of, but I wouldn't count on it)
Taking out mutexes isn't free. Cheap, yes, but not free, and those 20ns
mutex aquisition and releases do add up after a while.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
