> > 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