=head1 DESCRIPTION
+ WARNING: Threading is an experimental feature. Both the interface
+ and implementation are subject to change drastically. In fact, this
+ documentation describes the flavor of threads that was in version
+ 5.005. Perl 5.6.0 and later have the beginnings of support for
+ interpreter threads, which (when finished) is expected to be
+ significantly different from what is described here. The information
+ contained here may therefore soon be obsolete. Use at your own risk!
+
One of the most prominent new features of Perl 5.005 is the inclusion
of threads. Threads make a number of things a lot easier, and are a
very useful addition to your bag of programming tricks.
=head2 Ignoring A Thread
-join() does three things:it waits for a thread to exit, cleans up
+join() does three things: it waits for a thread to exit, cleans up
after it, and returns any data the thread may have produced. But what
if you're not interested in the thread's return values, and you don't
really care when the thread finishes? All you want is for the thread
Perl's scoping rules don't change because you're using threads. If a
subroutine (or block, in the case of async()) could see a variable if
you weren't running with threads, it can see it if you are. This is
-especially important for the subroutines that create, and makes my
+especially important for the subroutines that create, and makes C<my>
variables even more important. Remember--if your variables aren't
-lexically scoped (declared with C<my>) you're probably sharing it between
-threads.
+lexically scoped (declared with C<my>) you're probably sharing them
+between threads.
=head2 Thread Pitfall: Races
find it useful to synchronize access to subroutines. You may be
accessing a singular machine resource (perhaps a vector processor), or
find it easier to serialize calls to a particular subroutine than to
-have a set of locks and sempahores.
+have a set of locks and semaphores.
One of the additions to Perl 5.005 is subroutine attributes. The
Thread package uses these to provide several flavors of
The basic subroutine lock looks like this:
- sub test_sub {
- use attrs qw(locked);
+ sub test_sub :locked {
}
This ensures that only one thread will be executing this subroutine at
new Thread \&thread_sub, 3;
new Thread \&thread_sub, 4;
- sub sync_sub {
- use attrs qw(locked);
+ sub sync_sub :locked {
my $CallingThread = shift @_;
print "In sync_sub for thread $CallingThread\n";
yield;
print "$ThreadID is done with sync_sub\n";
}
-The use attrs qw(locked) locks sync_sub(), and if you run this, you
-can see that only one thread is in it at any one time.
+The C<locked> attribute tells perl to lock sync_sub(), and if you run
+this, you can see that only one thread is in it at any one time.
=head2 Methods
return bless [@_], $class;
}
- sub per_object {
- use attrs qw(locked method);
+ sub per_object :locked :method {
my ($class, $thrnum) = @_;
print "In per_object for thread $thrnum\n";
yield;
print "Exiting per_object for thread $thrnum\n";
}
- sub one_at_a_time {
- use attrs qw(locked);
+ sub one_at_a_time :locked {
my ($class, $thrnum) = @_;
print "In one_at_a_time for thread $thrnum\n";
yield;
=head2 Locking A Subroutine
-You can lock a subroutine as you would lock a variable. Subroutine
-locks work the same as a C<use attrs qw(locked)> in the subroutine,
+You can lock a subroutine as you would lock a variable. Subroutine locks
+work the same as specifying a C<locked> attribute for the subroutine,
and block all access to the subroutine for other threads until the
lock goes out of scope. When the subroutine isn't locked, any number
of threads can be in it at once, and getting a lock on a subroutine
lock(\&sub_to_lock);
-Simple enough. Unlike use attrs, which is a compile time option,
-locking and unlocking a subroutine can be done at runtime at your
+Simple enough. Unlike the C<locked> attribute, which is a compile time
+option, locking and unlocking a subroutine can be done at runtime at your
discretion. There is some runtime penalty to using lock(\&sub) instead
-of use attrs qw(locked), so make sure you're choosing the proper
+of the C<locked> attribute, so make sure you're choosing the proper
method to do the locking.
You'd choose lock(\&sub) when writing modules and code to run on both
A complete thread tutorial could fill a book (and has, many times),
but this should get you well on your way. The final authority on how
-Perl's threads behave is the documention bundled with the Perl
+Perl's threads behave is the documentation bundled with the Perl
distribution, but with what we've covered in this article, you should
be well on your way to becoming a threaded Perl expert.
0-201-52739-1.
Tanenbaum, Andrew S. Distributed Operating Systems. Prentice Hall,
-1995, ISBN 0-13-143934-0 (great textbook).
+1995, ISBN 0-13-219908-4 (great textbook).
Silberschatz, Abraham, and Peter B. Galvin. Operating System Concepts,
4th ed. Addison-Wesley, 1995, ISBN 0-201-59292-4