> > 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.
I think "is parallel" denotes something as usable by multiple threads
simultaneously, "in parallel".
"is serial" would denote that only one thread can use the $thing at a time,
exclusively.
>
> > 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?
After reading your comment, I realize the whole direction I started thinking
about this is all wrong.
More on that in a minute, after coffee.
> 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?
>
Perhaps some more syntax-play is in order here.
<disclamer>
I should note that my only experience with threading under Perl5 is via
threads.pm (and forks.pm).
I have not written multi-threaded applications using anything else (Java,
.Net, etc).
I have, however written several critical (to our business) applications that
depend on threads.pm and/or forks.pm
</disclamer>
One thing about threading with Perl5 is that it is easy to write a simple
threaded program that is entirely opaque - unless you
wrote the program yourself.
The program below gets a list of coderefs and executes each one, then returns
the result.
#================================================
(Using the threads.pm way...)
package QueueRunner;
use strict;
use threads;
use threads::shared;
sub process_job_queue
{
my ($s, @jobs_in) = @_;
my @results : shared = ();
my @workers = ();
push @workers, async { push( @results, $_->() ) } foreach @jobs_in;
$_->join foreach @workers;
return @results;
}# end process_job_queue()
# Elsewhere...
package main;
my @answer = QueueRunner->process_job_queue( \&job1, \&job2, \&job3 );
#================================================
And my attempt at the same, using Perl6:
#================================================
class QueueRunner {
our sub process_job_queue( Code @jobs_in ) returns List of Any {
my Any @results is parallel;
my Thread @workers = ();
for @jobs_in {
@workers.push( async { &_() } );
}
for @workers {
@results.push( $_.join() );
}
return @results;
}# end process_job_queue()
}# end QueueRunner
# Elsewhere...
my @answer = QueueRunner.process_job_queue( @jobs );
#================================================
I made absolutely no progress here. It seems to me that it's no more obvious
what's going on here than in the Perl5 version. Any
comments?
Regards,
John Drago
