--- John Drago <[EMAIL PROTECTED]> wrote:
> James Mastros wrote:
> > I don't like the name synchronized -- it implies that multiple
> > things are happening at the same time, as in synchronized swiming,
> > which is exactly the opposite of what should be implied.
> > "Serialized" would be a nice name, except it implies serializing
> > to a serial format, like disk. "Locked" is the best name I can
> > think of, and it frankly isn't that good -- it's so vauge as to
> > be able to mean almost anything.
> > . . .
>
> Agreed - maybe "is serial" instead, which suggests "is parallel"
> would be its implicit counterpart.
You mean "is parallel" as a synonym for "is async"? I actually like it
better, but that's just me.
> If we have a situation that looks like this:
>
> our method TakesForever ( int $num is serial ) is async {
> # Do something that takes a long time...then:
> $num++;
> # $num has not been changed by anything else that might
> # have access to $num.
> }
>
> my $age = 27;
> TakesForever( $age );
> $age += 20; # Fails somehow, because &TakesForever is working on $num
Hmm....
Is "fails somehow" the default?
I was thinking the better default would be more like standard
threading.
If $age has been passed to an asynchronous closure, it should be marked
as locked, and other threads trying to access it would have to get a
lock first. Yes, lots of overhead.... but that way if the default is
WAIT (which seems the smart default to me), the thread waits until
TakesForever() releases the resource.
if we declare
our method TakesForever ( int $num is serial ) is async but NOWAIT {
...
}
or
my $age = 27 but NOWAIT;
or
TakesForever( $age but NOWAIT );
(or whatever) then I'd say it should just fail. I mean, isn't that kind
of the idea, to have that sort of flexibility?
> Maybe a better example is needed - this one is pretty contrived.
I dunno. It gets a point across.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
