This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Thread Programming Model =head1 VERSION Maintainer: Steven McDougall <[EMAIL PROTECTED]> Date: 31 Aug 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 185 Status: Developing =head1 ABSTRACT use Thread; $thread = new Thread \&func , @args; $thread = new Thread sub { ... }, @args; async { ... }; $result = join $thread; $thread = this Thread; @threads = all Thread; $thread1 == $thread2 and ... yield(); critical { ... }; # one thread at a time in this block $mutex = new Mutex; lock $mutex; $ok = try $mutex; unlock $mutex; $semaphore = new Semaphore $initial; $ok = $semaphore->up($n); $semaphore->down; $event = auto Event; $event = manual Event; set $event; reset $event; wait $event; $timer = Timer->delay($seconds); $timer = Timer->alarm($time); $timer->wait; $readable = $fh->readable; $writable = $fh->writable; $failure = $fh->failure; $ok = wait_all(@objects); $i = wait_any(@objects); =head1 DESCRIPTION C<Thread> provides the programming interface to Perl6 threads. It includes a rich set of synchronization facilities. =head2 Thread =over 4 =item I<$thread> = C<new> C<Thread> \&I<func>, I<@args> Executes I<func>(I<@args>) in a separate thread. The return value is a reference to a C<Thread> object that manages the thread. =item I<$thread> = C<new> C<Thread> C<sub> { ... }, I<@args> Executes an anonymous subroutine in a separate thread, passing it I<@args>. The return value is a reference to a C<Thread> object that manages the thread. The subroutine executes in its enclosing lexical context. References to lexical variables in the enclosing context are bound at thread creation time, in a manner analogous to closures. =item C<async> BLOCK Executes BLOCK in a separate thread. Syntactically, C<async> BLOCK works like C<do> BLOCK. In particular, it does not return a C<Thread> object. If you want the thread object, use one of the C<new> C<Thread> forms shown above. The BLOCK executes in its enclosing lexical context. References to lexical variables in the enclosing context are bound at thread creation time, in a manner analogous to closures. =item I<$thread> = C<this> C<Thread> Returns a reference to the C<Thread> object that manages the current thread. =item I<@threads> = C<all> C<Thread> Returns a list of references to all existing C<Thread> objects in the program. =item I<$result> = C<join> I<$thread> =item I<@result> = C<join> I<$thread> Blocks until I<$thread> terminates. May be called repeatedly, by any number of threads. Returns the last expression evaluated in I<$thread>. This expression is evaluated in list context inside the thread. If C<join> is called in list context, it returns the entire list; if C<join> is called in scalar context, it returns the first element of the list. =item I<$thread1> == I<$thread2> Evaluates to true iff I<$thread1> and I<$thread2> reference the same C<Thread> object. =item C<yield>() Gives the interpreter an opportunity to switch to another thread. The interpreter is not obligated to take this opportunity, and the calling thread may regain control after an arbitrarily short period of time. =back =head2 Critical section C<critical> is a new keyword. Syntactically, it works like C<do>. critical { ... }; The interpreter guarantees that only one thread at a time can execute a C<critical> block. =head2 Mutex =over 4 =item I<$mutex> = C<new> C<Mutex> Creates and returns a new C<Mutex> object. =item C<lock> I<$mutex> If I<$mutex> is unlocked, locks it and returns immediately. If I<$mutex> is locked, blocks until I<$mutex> is unlocked. =item I<$ok> = C<try> I<$mutex> If I<$mutex> is unlocked, locks it and returns true. If I<$mutex> is locked, returns false. C<try> never blocks. =item I<$ok> = C<unlock> I<$mutex> If I<$mutex> was locked by the calling thread, unlocks it and returns true. If I<$mutex> is not locked, or was locked by another thread, does nothing and returns false. =back =head2 Semaphore A semaphore manages a number, called a I<count>. The count is always between zero and a system-dependent maximum. C<up> and C<down> are guaranteed to execute atomically. =over 4 =item I<$semaphore> = C<new> C<Semaphore> I<$n> Creates and returns a new C<Semaphore> object, with an initial count of I<$n>. If I<$n> is omitted, the initial count is zero. =item I<$ok> = C<$semaphore>->C<up>(I<$n>) If the count can be increased by I<$n> without exceeding the maximum, does so and returns true. Otherwise, does nothing and returns false. If I<$n> is omitted, it defaults to 1. =item I<$semaphore>->C<down> Blocks until the count is positive, then decrements the count and returns. =back =head2 Event Events allow one thread to wait until something happens in another thread. Events have two states: I<set> and I<reset>. Threads I<wait> on an event; the C<wait> call blocks until the event is set. There are two kinds of events: I<manual> and I<automatic>. When a manual event is set, it remains set until a C<reset> call is made on it. All waiting threads are immediately unblocked, and subsequent calls to C<wait> return immediately. When an automatic event is set, one waiting thread is unblocked and the event is immediately reset. If there are no waiting threads, the first call to C<wait> resets the event and returns immediately. =over 4 =item I<$event> = C<auto> C<Event> Creates and returns an automatic C<Event> object. The event is initially reset. =item I<$event> = C<manual> C<Event> Creates and returns a manual C<Event> object. The event is initially reset. =item C<set> I<$event> Sets I<$event>. When a manual event is set, it remains set until a C<reset> call is made on it. During this time, any number of threads may C<wait> on it without blocking. When an automatic event is set, it is reset by the first thread that C<wait>s on it. =item C<reset> I<$event> Resets I<$event>. =item C<wait> I<$event> Blocks until I<$event> is set. =back =head2 Timer =over 4 =item I<$timer> = C<Timer>->C<delay>(I<$seconds>) Creates and returns a new C<Timer> object. The timer will expire I<$seconds> seconds after it is created. I<$seconds> may be a floating point number, so this interface supports whatever time resolution the platform provides. =item I<$timer> = C<Timer>->C<alarm>(I<$time>) Creates and returns a new C<Timer> object. The timer will expire at I<$time> seconds after the epoch. I<$time> may be floating point number, so this interface supports whatever time resolution the platform provides. =item C<wait> I<$timer> Blocks until the timer expires. =back =head2 Wait functions Threads, mutexes, semaphores, events, and timers are collectively referred to collectively as I<synchronization objects>. In addition, we can create C<readable>, C<writable>, and C<failure> objects from a file handle. A synchronization object is said to be I<signaled> when a thread would not block on it. The conditions for an object to be signaled depend on the kind of object. =over 4 =item * Threads are signaled when they have completed execution. =item * Mutexes are signaled with they are unlocked. =item * Semaphores are signaled when they have a positive count. =item * Events are signaled while they are set. =item * Timers are signaled when they expire =item * Readable objects are signaled when a read on the underlying file handle will not block. =item * Writable objects are signaled when a write on the underlying file handle will not block. =item * Failure objects are signaled when I/O on the underlying file handle will fail. =back =over 4 =item I<$readable> = I<$fh>->C<readable> Returns a synchronization object that is signaled when there is data available to be read on I<$fh>. =item I<$writable> = I<$fh>->C<writable> Returns a synchronization object that is signaled when a write to <$fh> will not block =item I<$failure> = I<$fh>->C<failure> Returns a synchronization object that is signaled when I/O operations on I<$fh> will fail. =item I<$ok> = wait_all(@objects) Blocks until all of the synchronization I<@objects> are signaled. C<wait_all> does not change the state of any object until all the objects are signaled. This prevents deadlock, at least between competing wait functions. Returns true on success, false on error. An error occurs if an element of I<@objects> is not a synchronization object. =item I<$i> = wait_any(@objects); Blocks until at least one of the synchronization I<@objects> is signaled. On success, returns the index in I<@objects> of a signaled object. Returns -1 on error. An error occurs if an element of I<@objects> is not a synchronization object. =back =head1 IMPLEMENTATION All of these features should be doable if threads are built into Perl. Making file handles and sockets into synchronization objects probably requires asynchronous I/O. Not everything has to be in the core. For example, semaphores are easily built out of mutexes. =head1 DISCUSSION This interface is an amalgam of =over 4 =item * the C<Thread.pm> interface from Perl 5.6.0 =item * the Win32 thread interface =item * my own wish list (you can't get it if you don't ask...) =back Here are some issues to consider =head2 Thread creation Threads are created by new Thread \&func new Thread sub { ... } async { ... } We arguably don't need three different ways to create threads. However, the different syntaxes fit into the language in slightly different ways, and I'm not sure which one I'd be willing to give up. The first is the most fundamental; losing it would be a serious inconvenience. Perl generally allows an anonymous subroutine where ever it allows a code ref, so the second also seems appropriate. And the third allows us to create threads with the kind of lightweight syntax that makes Perl such a fluent language. =head2 C<join> The calling context of C<join> can't be propagated into the thread, for several reasons. =over 4 =item * The thread can compute only one return value, but C<join> can be called repeatedly in different contexts. =item * The thread might terminate before the first call to join. C<join> can return the last expression evaluated in the thread, but it can't retroactively affect the context in which that expression was evaluated. =back Not allowing multiple C<join>s on a thread might help with the first problem; I can't see any way around the second. =head2 Critical sections This interface provides the critical { ... } construct. In principle, we don't need this: you can always do the same thing with a mutex { lock $mutex; ... unlock $mutex; } Nonetheless, critical sections have several attractive features. =over 4 =item * They reduce clutter. No mutex to create and lock and unlock. =item * Along with less clutter comes fewer chances for bugs. There isn't a mutex floating around to get abandoned (locked by a thread that has terminated), or locked twice by the same thread, or locked by the wrong thread, or locked and never unlocked, or... =item * The implementation can be highly optimized. Internally, a critical section is still protected by some kind of mutex. However, this mutex isn't user visible: the interpreter has complete control over it. Therefore, it can be very lightweight. =back Efficiency matters, because critical sections are used to manage things that are...well...critical. Important, global, high-contention resources like memory managers and process schedulers. Granted, these are poor examples for Perl, but you get the idea. There are other kinds of built-in serialization mechanisms. For example, Java provides one mutex per object; all method calls on the object are serialized. C<Threads.pm> documents a C<lock(&sub)> call and a C<:locked> attribute for subroutines. The problem with these approaches is that they tie serialization to other language structures, and those structures may not be at the right granularity for a particular application. For example, a class may have some methods that require serialization and some that do not; a mutex that automatically serializes all method calls on the object needlessly reduces performance (and increases the chances for deadlock). Conversely, an application may need to serialize access to a subsystem that comprises multiple objects. In this case, the programmer has to create and manage their own mutexes; the built-in mutexes don't help with this. Similarly, the C<lock(&sub)> call and the C<:locked> attribute co-opt the subroutine structure of the program in favor of synchronization. Subroutine structure should driven by program design, not dictated by language features. =head2 Mutexes I dropped the lock($scalar) call from this interface in favor of Mutexes. The two features provide roughly the same functionality, so this is partly a matter style. One possible reason to prefer mutexes is to simplify implementation of C<wait_all> and C<wait_one>. I'm open to use cases on this. =head2 Events I dropped the C<cond_wait> mechanism in C<Threads.pm> in favor of Events. Events do essentially the same thing with a simpler interface. In particular, Events don't expose a mutex the way C<cond_wait> does. (As far as I can tell, this mutex is an artifact of the PThreads implementation.) One substantive difference between Events and C<cond_wait> is that the manual/automatic distinction for Events is a property of the Event object, while the corresponding broadcast/signal distinction for C<cond_wait> is a property of the signaling call. I'm open to use cases that would show a preference for one of these architectures over the other. =head2 C<die> I dropped the I<$thread>->C<eval> call from this interface, and didn't say what happens if a thread C<die>s. There are several possibilities =over 4 =item * The exception is propagated to any thread that C<join>s it. This has a certain logic to it, but it suffers from the fact that a program needn't C<join> its threads, so it doesn't guarantee that exceptions will actually be handled. =item * The interpreter prints C<$@> on stderr and exits. This is what C++ does. It ensures that exceptions won't just disappear into the void; however, it also causes a good deal of anxiety and paranoia, because I<any> thread can potentially blow your program out of the water. (I speak from experience here.) =item * The thread just quietly goes away. After working with threads in C++, I'm actually partial to this one. We still need some way to recover C<$@> when a thread C<die>s. Returning C<$@> to C<join> is probably the Wrong Thing. =back =head2 C<==> I dropped I<$thread>->C<equal> in favor of overloading C<==> to compare threads. This seems more natural, and should be easy to implement if threads are built into the language. =head2 Thread IDs I dropped thread IDs from the interface. You don't want thread IDs. Thread IDs are an implementation artifact. Carrying around explicit numerical indices isn't the Perl way. They were broken anyway (wrap at 2^32, with no guarantee of uniqueness after that). =head2 Detach I dropped C<detach> from the interface. Detach is an artifact of languages that require programmers to manage their own storage. It has rigorous semantics, there's no going back, and if you get it wrong, you either leak threads or you crash. In Perl, detachment is more a state of mind. We have threads, and we have C<Thread> objects to manage them. The thread holds a reference on its C<Thread> object until it terminates. The C<Thread> object holds a reference on its thread as long as the C<Thread> object exists. If there are no user-visible references to a C<Thread> object (i.e. the only reference on the C<Thread> object is the one held by the thread), then the thread is said to be detached. A call to C<Thread>->C<all> or C<Thread>->C<this> could recover a reference to the C<Thread> object of a detached thread; when this happens, the thread is no longer detached. In any case, you don't have to worry about it. Like so many others, C<detach> is a problem that Perl doesn't have. =head2 Semaphores PThreads allows an application to get the current count of a semaphore. This feature is useless, and an open invitation to bugs. It does not appear in this interface. =head2 Import To minimize namespace pollution, we could @EXPORT_OK the functions that appear in this interface. use Threads qw(yield wait_all wait_any) On the other hand, if they get moved into the core, the issue is probably moot. =head2 Wait functions C<wait_all> and C<wait_one> are generalizations of the C<select>(2) Unix system call and the C<WaitForMultipleObjects> Win32 call. C<readable>, C<writable>, and C<failure> are documented as being file handle methods; however, it is anticipated that file handles will subsume sockets in Perl6. For an unconnected socket, the semantics of C<readable> are extended so that it is signaled when a C<connect> or C<accept> call will not block. Allowing applications to block on network I/O in a controlled fashion is an important use of the wait functions. The wait functions may seem overdone; however, applications really do need these features, and they can be I<very> difficult to implement without language support. For example, C<select>(2) doesn't work with file descriptors for the console, and C<WaitForMultipleObjects> doesn't work with sockets. I have direct experience with the difficulty of programming around these deficiencies. An outstanding problem with the interface documented here is that it does not guarantee that a socket will still be readable or writable at the time the application actually attempts I/O, nor does it indicate I<how many> bytes may be read or written without blocking. A better approach might be to do asynchronous I/O, and obtain a synchronization object that is signaled when the I/O operation completes. I hesitate to specify such an interface until there is more definition for file handles and asynchronous I/O in Perl6. =head2 Timer There are two kinds of timers: relative and absolute. Obviously, you can always build one kind out of the other, but I wanted to distinguish them with different constructors. I named the constructors C<delay> and C<alarm>, respectively. These are short, and read fairly naturally. =head2 C<this Thread> C++ partisans will get brain freeze reading code like my $thread = this Thread; but that's not why I traded in C<self> for C<this>. Really. I did it because it reads more naturally to me. =head1 REFERENCES RFC 1: Implementation of Threads in Perl RFC 27: Coroutines for Perl RFC 31: Co-routines RFC 47: Universal Asynchronous I/O RFC 178: Lightweight Threads Threads.pm PThreads info page
