Penguin
Recent Changes
Blame: perlthrtut(1)
EditPageHistoryDiffInfoLikePages
Annotated edit history of perlthrtut(1) version 2, including all changes. View license author blame.
Rev Author # Line
1 perry 1 PERLTHRTUT
2 !!!PERLTHRTUT
3 NAME
4 DESCRIPTION
5 What Is A Thread Anyway?
6 Threaded Program Models
7 Native threads
8 What kind of threads are perl threads?
9 Threadsafe Modules
10 Thread Basics
11 Threads And Data
12 Threads And Code
13 General Thread Utility Routines
14 A Complete Example
15 Conclusion
16 Bibliography
17 Acknowledgements
18 AUTHOR
19 Copyrights
20 ----
21 !!NAME
22
23
24 perlthrtut - tutorial on threads in Perl
25 !!DESCRIPTION
26
27
28 WARNING: Threading is an experimental feature. Both the interface
29 and implementation are subject to change drastically. In fact, this
30 documentation describes the flavor of threads that was in version
31 5.005. Perl 5.6.0 and later have the beginnings of support for
32 interpreter threads, which (when finished) is expected to be
33 significantly different from what is described here. The information
34 contained here may therefore soon be obsolete. Use at your own risk!
35 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.
36 !!What Is A Thread Anyway?
37
38
39 A thread is a flow of control through a program with a
40 single execution point.
41
42
43 Sounds an awful lot like a process, doesn't it? Well, it
44 should. Threads are one of the pieces of a process. Every
45 process has at least one thread and, up until now, every
46 process running Perl had only one thread. With 5.005,
47 though, you can create extra threads. We're going to show
48 you how, when, and why.
49 !!Threaded Program Models
50
51
52 There are three basic ways that you can structure a threaded
53 program. Which model you choose depends on what you need
54 your program to do. For many non-trivial threaded programs
55 you'll need to choose different models for different pieces
56 of your program.
57
58
59 __Boss/Worker__
60
61
62 The boss/worker model usually has one `boss' thread and one
63 or more `worker' threads. The boss thread gathers or
64 generates tasks that need to be done, then parcels those
65 tasks out to the appropriate worker thread.
66
67
68 This model is common in GUI and server
69 programs, where a main thread waits for some event and then
70 passes that event to the appropriate worker threads for
71 processing. Once the event has been passed on, the boss
72 thread goes back to waiting for another event.
73
74
75 The boss thread does relatively little work. While tasks
76 aren't necessarily performed faster than with any other
77 method, it tends to have the best user-response
78 times.
79
80
81 __Work Crew__
82
83
84 In the work crew model, several threads are created that do
85 essentially the same thing to different pieces of data. It
86 closely mirrors classical parallel processing and vector
87 processors, where a large array of processors do the exact
88 same thing to many pieces of data.
89
90
91 This model is particularly useful if the system running the
92 program will distribute multiple threads across different
93 processors. It can also be useful in ray tracing or
94 rendering engines, where the individual threads can pass on
95 interim results to give the user visual
96 feedback.
97
98
99 __Pipeline__
100
101
102 The pipeline model divides up a task into a series of steps,
103 and passes the results of one step on to the thread
104 processing the next. Each thread does one thing to each
105 piece of data and passes the results to the next thread in
106 line.
107
108
109 This model makes the most sense if you have multiple
110 processors so two or more threads will be executing in
111 parallel, though it can often make sense in other contexts
112 as well. It tends to keep the individual tasks small and
113 simple, as well as allowing some parts of the pipeline to
114 block (on I/O or system calls, for example) while other
115 parts keep going. If you're running different parts of the
116 pipeline on different processors you may also take advantage
117 of the caches on each processor.
118
119
120 This model is also handy for a form of recursive programming
121 where, rather than having a subroutine call itself, it
122 instead creates another thread. Prime and Fibonacci
123 generators both map well to this form of the pipeline model.
124 (A version of a prime number generator is presented later
125 on.)
126 !!Native threads
127
128
129 There are several different ways to implement threads on a
130 system. How threads are implemented depends both on the
131 vendor and, in some cases, the version of the operating
132 system. Often the first implementation will be relatively
133 simple, but later versions of the OS will be
134 more sophisticated.
135
136
137 While the information in this section is useful, it's not
138 necessary, so you can skip it if you don't feel up to
139 it.
140
141
142 There are three basic categories of threads-user-mode
143 threads, kernel threads, and multiprocessor kernel
144 threads.
145
146
147 User-mode threads are threads that live entirely within a
148 program and its libraries. In this model, the
149 OS knows nothing about threads. As far as
150 it's concerned, your process is just a process.
151
152
153 This is the easiest way to implement threads, and the way
154 most OSes start. The big disadvantage is that, since the
155 OS knows nothing about threads, if one thread
156 blocks they all do. Typical blocking activities include most
157 system calls, most I/O, and things like
158 ''sleep()''.
159
160
161 Kernel threads are the next step in thread evolution. The
162 OS knows about kernel threads, and makes
163 allowances for them. The main difference between a kernel
164 thread and a user-mode thread is blocking. With kernel
165 threads, things that block a single thread don't block other
166 threads. This is not the case with user-mode threads, where
167 the kernel blocks at the process level and not the thread
168 level.
169
170
171 This is a big step forward, and can give a threaded program
172 quite a performance boost over non-threaded programs.
173 Threads that block performing I/O, for example, won't block
174 threads that are doing other things. Each process still has
175 only one thread running at once, though, regardless of how
176 many CPUs a system might have.
177
178
179 Since kernel threading can interrupt a thread at any time,
180 they will uncover some of the implicit locking assumptions
181 you may make in your program. For example, something as
182 simple as $a = $a + 2 can behave unpredictably with
183 kernel threads if $a is visible to other threads,
184 as another thread may have changed $a between the
185 time it was fetched on the right hand side and the time the
186 new value is stored.
187
188
189 Multiprocessor Kernel Threads are the final step in thread
190 support. With multiprocessor kernel threads on a machine
191 with multiple CPUs, the OS may schedule two
192 or more threads to run simultaneously on different
193 CPUs.
194
195
196 This can give a serious performance boost to your threaded
197 program, since more than one thread will be executing at the
198 same time. As a tradeoff, though, any of those nagging
199 synchronization issues that might not have shown with basic
200 kernel threads will appear with a vengeance.
201
202
203 In addition to the different levels of OS
204 involvement in threads, different OSes (and different thread
205 implementations for a particular OS )
206 allocate CPU cycles to threads in different
207 ways.
208
209
210 Cooperative multitasking systems have running threads give
211 up control if one of two things happen. If a thread calls a
212 yield function, it gives up control. It also gives up
213 control if the thread does something that would cause it to
214 block, such as perform I/O. In a cooperative multitasking
215 implementation, one thread can starve all the others for
216 CPU time if it so chooses.
217
218
219 Preemptive multitasking systems interrupt threads at regular
220 intervals while the system decides which thread should run
221 next. In a preemptive multitasking system, one thread
222 usually won't monopolize the CPU
223 .
224
225
226 On some systems, there can be cooperative and preemptive
227 threads running simultaneously. (Threads running with
228 realtime priorities often behave cooperatively, for example,
229 while threads running at normal priorities behave
230 preemptively.)
231 !!What kind of threads are perl threads?
232
233
234 If you have experience with other thread implementations,
235 you might find that things aren't quite what you expect.
236 It's very important to remember when dealing with Perl
237 threads that Perl Threads Are Not X Threads, for all values
238 of X. They aren't POSIX threads, or
2 perry 239 !DecThreads, or Java's Green threads, or Win32 threads. There
1 perry 240 are similarities, and the broad concepts are the same, but
241 if you start looking for implementation details you're going
242 to be either disappointed or confused. Possibly
243 both.
244
245
246 This is not to say that Perl threads are completely
247 different from everything that's ever come before--they're
248 not. Perl's threading model owes a lot to other thread
249 models, especially POSIX . Just as Perl is
250 not C, though, Perl threads are not POSIX
251 threads. So if you find yourself looking for mutexes, or
252 thread priorities, it's time to step back a bit and think
253 about what you want to do and how Perl can do
254 it.
255 !!Threadsafe Modules
256
257
258 The addition of threads has changed Perl's internals
259 substantially. There are implications for people who write
260 modules--especially modules with XS code or
261 external libraries. While most modules won't encounter any
262 problems, modules that aren't explicitly tagged as
263 thread-safe should be tested before being used in production
264 code.
265
266
267 Not all modules that you might use are thread-safe, and you
268 should always assume a module is unsafe unless the
269 documentation says otherwise. This includes modules that are
270 distributed as part of the core. Threads are a beta feature,
271 and even some of the standard modules aren't
272 thread-safe.
273
274
275 If you're using a module that's not thread-safe for some
276 reason, you can protect yourself by using semaphores and
277 lots of programming discipline to control access to the
278 module. Semaphores are covered later in the article. Perl
279 Threads Are Different
280 !!Thread Basics
281
282
283 The core Thread module provides the basic functions you need
284 to write threaded programs. In the following sections we'll
285 cover the basics, showing you what you need to do to create
286 a threaded program. After that, we'll go over some of the
287 features of the Thread module that make threaded programming
288 easier.
289
290
291 __Basic Thread Support__
292
293
294 Thread support is a Perl compile-time option-it's something
295 that's turned on or off when Perl is built at your site,
296 rather than when your programs are compiled. If your Perl
297 wasn't compiled with thread support enabled, then any
298 attempt to use threads will fail.
299
300
301 Remember that the threading support in 5.005 is in beta
302 release, and should be treated as such. You should expect
303 that it may not function entirely properly, and the thread
304 interface may well change some before it is a fully
305 supported, production release. The beta version shouldn't be
306 used for mission-critical projects. Having said that,
307 threaded Perl is pretty nifty, and worth a
308 look.
309
310
311 Your programs can use the Config module to check whether
312 threads are enabled. If your program can't run without them,
313 you can say something like:
314
315
316 $Config{usethreads} or die
317 A possibly-threaded program using a possibly-threaded module might have code like this:
318
319
320 use Config;
2 perry 321 use !MyMod;
1 perry 322 if ($Config{usethreads}) {
323 # We have threads
2 perry 324 require !MyMod_threaded;
325 import !MyMod_threaded;
1 perry 326 } else {
2 perry 327 require !MyMod_unthreaded;
328 import !MyMod_unthreaded;
1 perry 329 }
2 perry 330 Since code that runs both with and without threads is usually pretty messy, it's best to isolate the thread-specific code in its own module. In our example above, that's what !MyMod_threaded is, and it's only imported if we're running on a threaded Perl.
1 perry 331
332
333 __Creating Threads__
334
335
336 The Thread package provides the tools you need to create new
337 threads. Like any other module, you need to tell Perl you
338 want to use it; use Thread imports all the pieces you need
339 to create basic threads.
340
341
342 The simplest, straightforward way to create a thread is with
343 ''new()'':
344
345
346 use Thread;
347 $thr = new Thread
348 sub sub1 {
349 print
350 The ''new()'' method takes a reference to a subroutine and creates a new thread, which starts executing in the referenced subroutine. Control then passes both to the subroutine and the caller.
351
352
353 If you need to, your program can pass parameters to the
354 subroutine as part of the thread startup. Just include the
355 list of parameters as part of the Thread::new call,
356 like this:
357
358
359 use Thread;
360 $Param3 =
361 sub sub1 {
2 perry 362 my @!InboundParameters = @_;
1 perry 363 print
364 The subroutine runs like a normal Perl subroutine, and the call to new Thread returns whatever the subroutine returns.
365
366
367 The last example illustrates another feature of threads. You
368 can spawn off several threads using the same subroutine.
369 Each thread executes the same subroutine, but in a separate
370 thread with a separate environment and potentially separate
371 arguments.
372
373
374 The other way to spawn a new thread is with ''async()'',
375 which is a way to spin off a chunk of code like
376 ''eval()'', but into its own thread:
377
378
379 use Thread qw(async);
2 perry 380 $!LineCount = 0;
1 perry 381 $thr = async {
382 while(
383 print
384 You'll notice we did a use Thread qw(async) in that example. async is not exported by default, so if you want it, you'll either need to import it before you use it or fully qualify it as Thread::async. You'll also note that there's a semicolon after the closing brace. That's because ''async()'' treats the following block as an anonymous subroutine, so the semicolon is necessary.
385
386
387 Like ''eval()'', the code executes in the same context as
388 it would if it weren't spun off. Since both the code inside
389 and after the async start executing, you need to be careful
390 with any shared resources. Locking and other synchronization
391 techniques are covered later.
392
393
394 __Giving up control__
395
396
397 There are times when you may find it useful to have a thread
398 explicitly give up the CPU to another thread.
399 Your threading package might not support preemptive
400 multitasking for threads, for example, or you may be doing
401 something compute-intensive and want to make sure that the
402 user-interface thread gets called frequently. Regardless,
403 there are times that you might want a thread to give up the
404 processor.
405
406
407 Perl's threading package provides the ''yield()''
408 function that does this. ''yield()'' is pretty
409 straightforward, and works like this:
410
411
412 use Thread qw(yield async);
413 async {
414 my $foo = 50;
415 while ($foo--) { print
416
417
418 __Waiting For A Thread To Exit__
419
420
421 Since threads are also subroutines, they can return values.
422 To wait for a thread to exit and extract any scalars it
423 might return, you can use the ''join()''
424 method.
425
426
427 use Thread;
428 $thr = new Thread
2 perry 429 @!ReturnData = $thr-
1 perry 430 sub sub1 { return
431 In the example above, the ''join()'' method returns as soon as the thread ends. In addition to waiting for a thread to finish and gathering up any values that the thread might have returned, ''join()'' also performs any OS cleanup necessary for the thread. That cleanup might be important, especially for long-running programs that spawn lots of threads. If you don't want the return values and don't want to wait for the thread to finish, you should call the ''detach()'' method instead. ''detach()'' is covered later in the article.
432
433
434 __Errors In Threads__
435
436
437 So what happens when an error occurs in a thread? Any errors
438 that could be caught with ''eval()'' are postponed until
439 the thread is joined. If your program never joins, the
440 errors appear when your program exits.
441
442
443 Errors deferred until a ''join()'' can be caught with
444 ''eval()'':
445
446
447 use Thread qw(async);
448 $thr = async {$b = 3/0}; # Divide by zero error
449 $foo = eval {$thr-
450 ''eval()'' passes any results from the joined thread back unmodified, so if you want the return value of the thread, this is your only chance to get them.
451
452
453 __Ignoring A Thread__
454
455
456 ''join()'' does three things: it waits for a thread to
457 exit, cleans up after it, and returns any data the thread
458 may have produced. But what if you're not interested in the
459 thread's return values, and you don't really care when the
460 thread finishes? All you want is for the thread to get
461 cleaned up after when it's done.
462
463
464 In this case, you use the ''detach()'' method. Once a
465 thread is detached, it'll run until it's finished, then Perl
466 will clean up after it automatically.
467
468
469 use Thread;
470 $thr = new Thread
471 $thr-
472 sub sub1 {
473 $a = 0;
474 while (1) {
475 $a++;
476 print
477 Once a thread is detached, it may not be joined, and any output that it might have produced (if it was done and waiting for a join) is lost.
478 !!Threads And Data
479
480
481 Now that we've covered the basics of threads, it's time for
482 our next topic: data. Threading introduces a couple of
483 complications to data access that non-threaded programs
484 never need to worry about.
485
486
487 __Shared And Unshared Data__
488
489
490 The single most important thing to remember when using
491 threads is that all threads potentially have access to all
492 the data anywhere in your program. While this is true with a
493 nonthreaded Perl program as well, it's especially important
494 to remember with a threaded program, since more than one
495 thread can be accessing this data at once.
496
497
498 Perl's scoping rules don't change because you're using
499 threads. If a subroutine (or block, in the case of
500 ''async()'') could see a variable if you weren't running
501 with threads, it can see it if you are. This is especially
502 important for the subroutines that create, and makes
503 my variables even more important. Remember--if your
504 variables aren't lexically scoped (declared with
505 my) you're probably sharing them between
506 threads.
507
508
509 __Thread Pitfall: Races__
510
511
512 While threads bring a new set of useful tools, they also
513 bring a number of pitfalls. One pitfall is the race
514 condition:
515
516
517 use Thread;
518 $a = 1;
519 $thr1 = Thread-
520 sleep 10;
521 print
522 sub sub1 { $foo = $a; $a = $foo + 1; }
523 sub sub2 { $bar = $a; $a = $bar + 1; }
524 What do you think $a will be? The answer, unfortunately, is ``it depends.'' Both ''sub1()'' and ''sub2()'' access the global variable $a, once to read and once to write. Depending on factors ranging from your thread implementation's scheduling algorithm to the phase of the moon, $a can be 2 or 3.
525
526
527 Race conditions are caused by unsynchronized access to
528 shared data. Without explicit synchronization, there's no
529 way to be sure that nothing has happened to the shared data
530 between the time you access it and the time you update it.
531 Even this simple code fragment has the possibility of
532 error:
533
534
535 use Thread qw(async);
536 $a = 2;
537 async{ $b = $a; $a = $b + 1; };
538 async{ $c = $a; $a = $c + 1; };
539 Two threads both access $a. Each thread can potentially be interrupted at any point, or be executed in any order. At the end, $a could be 3 or 4, and both $b and $c could be 2 or 3.
540
541
542 Whenever your program accesses data or resources that can be
543 accessed by other threads, you must take steps to coordinate
544 access or risk data corruption and race
545 conditions.
546
547
548 __Controlling access:__ ''lock()''
549
550
551 The ''lock()'' function takes a variable (or subroutine,
552 but we'll get to that later) and puts a lock on it. No other
553 thread may lock the variable until the locking thread exits
554 the innermost block containing the lock. Using ''lock()''
555 is straightforward:
556
557
558 use Thread qw(async);
559 $a = 4;
560 $thr1 = async {
561 $foo = 12;
562 {
563 lock ($a); # Block until we get access to $a
564 $b = $a;
565 $a = $b * $foo;
566 }
567 print
568 ''lock()'' blocks the thread until the variable being locked is available. When ''lock()'' returns, your thread can be sure that no other thread can lock that variable until the innermost block containing the lock exits.
569
570
571 It's important to note that locks don't prevent access to
572 the variable in question, only lock attempts. This is in
573 keeping with Perl's longstanding tradition of courteous
574 programming, and the advisory file locking that
575 ''flock()'' gives you. Locked subroutines behave
576 differently, however. We'll cover that later in the
577 article.
578
579
580 You may lock arrays and hashes as well as scalars. Locking
581 an array, though, will not block subsequent locks on array
582 elements, just lock attempts on the array
583 itself.
584
585
586 Finally, locks are recursive, which means it's okay for a
587 thread to lock a variable more than once. The lock will last
588 until the outermost ''lock()'' on the variable goes out
589 of scope.
590
591
592 __Thread Pitfall: Deadlocks__
593
594
595 Locks are a handy tool to synchronize access to data. Using
596 them properly is the key to safe shared data. Unfortunately,
597 locks aren't without their dangers. Consider the following
598 code:
599
600
601 use Thread qw(async yield);
602 $a = 4;
603 $b =
604 This program will probably hang until you kill it. The only way it won't hang is if one of the two ''async()'' routines acquires both locks first. A guaranteed-to-hang version is more complicated, but the principle is the same.
605
606
607 The first thread spawned by ''async()'' will grab a lock
608 on $a then, a second or two later, try to grab a
609 lock on $b. Meanwhile, the second thread grabs a
610 lock on $b, then later tries to grab a lock on
611 $a. The second lock attempt for both threads will
612 block, each waiting for the other to release its
613 lock.
614
615
616 This condition is called a deadlock, and it occurs whenever
617 two or more threads are trying to get locks on resources
618 that the others own. Each thread will block, waiting for the
619 other to release a lock on a resource. That never happens,
620 though, since the thread with the resource is itself waiting
621 for a lock to be released.
622
623
624 There are a number of ways to handle this sort of problem.
625 The best way is to always have all threads acquire locks in
626 the exact same order. If, for example, you lock variables
627 $a, $b, and $c, always lock
628 $a before $b, and $b before
629 $c. It's also best to hold on to locks for as short
630 a period of time to minimize the risks of
631 deadlock.
632
633
634 __Queues: Passing Data Around__
635
636
637 A queue is a special thread-safe object that lets you put
638 data in one end and take it out the other without having to
639 worry about synchronization issues. They're pretty
640 straightforward, and look like this:
641
642
643 use Thread qw(async);
644 use Thread::Queue;
2 perry 645 my $!DataQueue = new Thread::Queue;
1 perry 646 $thr = async {
2 perry 647 while ($!DataElement = $!DataQueue-
648 $!DataQueue-
1 perry 649 You create the queue with new Thread::Queue. Then you can add lists of scalars onto the end with ''enqueue()'', and pop scalars off the front of it with ''dequeue()''. A queue has no fixed size, and can grow as needed to hold everything pushed on to it.
650
651
652 If a queue is empty, ''dequeue()'' blocks until another
653 thread enqueues something. This makes queues ideal for event
654 loops and other communications between threads.
655 !!Threads And Code
656
657
658 In addition to providing thread-safe access to data via
659 locks and queues, threaded Perl also provides
660 general-purpose semaphores for coarser synchronization than
661 locks provide and thread-safe access to entire
662 subroutines.
663
664
665 __Semaphores: Synchronizing Data Access__
666
667
668 Semaphores are a kind of generic locking mechanism. Unlike
669 lock, which gets a lock on a particular scalar, Perl doesn't
670 associate any particular thing with a semaphore so you can
671 use them to control access to anything you like. In
672 addition, semaphores can allow more than one thread to
673 access a resource at once, though by default semaphores only
674 allow one thread access at a time.
675
676
677 Basic semaphores
678
679
680 Semaphores have two methods, down and up. down decrements
681 the resource count, while up increments it. down calls will
682 block if the semaphore's current count would decrement below
683 zero. This program gives a quick demonstration:
684
685
686 use Thread qw(yield);
687 use Thread::Semaphore;
688 my $semaphore = new Thread::Semaphore;
2 perry 689 $!GlobalVariable = 0;
1 perry 690 $thr1 = new Thread
691 sub sample_sub {
2 perry 692 my $!SubNumber = shift @_;
693 my $!TryCount = 10;
694 my $!LocalCopy;
1 perry 695 sleep 1;
2 perry 696 while ($!TryCount--) {
1 perry 697 $semaphore-
698 The three invocations of the subroutine all operate in sync. The semaphore, though, makes sure that only one thread is accessing the global variable at once.
699
700
701 Advanced Semaphores
702
703
704 By default, semaphores behave like locks, letting only one
705 thread ''down()'' them at a time. However, there are
706 other uses for semaphores.
707
708
709 Each semaphore has a counter attached to it. ''down()''
710 decrements the counter and ''up()'' increments the
711 counter. By default, semaphores are created with the counter
712 set to one, ''down()'' decrements by one, and ''up()''
713 increments by one. If ''down()'' attempts to decrement
714 the counter below zero, it blocks until the counter is large
715 enough. Note that while a semaphore can be created with a
716 starting count of zero, any ''up()'' or ''down()''
717 always changes the counter by at least one.
718 $semaphore-down''(0) is the same as
719 $semaphore-down''(1).
720
721
722 The question, of course, is why would you do something like
723 this? Why create a semaphore with a starting count that's
724 not one, or why decrement/increment it by more than one? The
725 answer is resource availability. Many resources that you
726 want to manage access for can be safely used by more than
727 one thread at once.
728
729
730 For example, let's take a GUI driven program.
731 It has a semaphore that it uses to synchronize access to the
732 display, so only one thread is ever drawing at once. Handy,
733 but of course you don't want any thread to start drawing
734 until things are properly set up. In this case, you can
735 create a semaphore with a counter set to zero, and up it
736 when things are ready for drawing.
737
738
739 Semaphores with counters greater than one are also useful
740 for establishing quotas. Say, for example, that you have a
741 number of threads that can do I/O at once. You don't want
742 all the threads reading or writing at once though, since
743 that can potentially swamp your I/O channels, or deplete
744 your process' quota of filehandles. You can use a semaphore
745 initialized to the number of concurrent I/O requests (or
746 open files) that you want at any one time, and have your
747 threads quietly block and unblock themselves.
748
749
750 Larger increments or decrements are handy in those cases
751 where a thread needs to check out or return a number of
752 resources at once.
753
754
755 __Attributes: Restricting Access To
756 Subroutines__
757
758
759 In addition to synchronizing access to data or resources,
760 you might find it useful to synchronize access to
761 subroutines. You may be accessing a singular machine
762 resource (perhaps a vector processor), or find it easier to
763 serialize calls to a particular subroutine than to have a
764 set of locks and semaphores.
765
766
767 One of the additions to Perl 5.005 is subroutine attributes.
768 The Thread package uses these to provide several flavors of
769 serialization. It's important to remember that these
770 attributes are used in the compilation phase of your program
771 so you can't change a subroutine's behavior while your
772 program is actually running.
773
774
775 __Subroutine Locks__
776
777
778 The basic subroutine lock looks like this:
779
780
781 sub test_sub :locked {
782 }
783 This ensures that only one thread will be executing this subroutine at any one time. Once a thread calls this subroutine, any other thread that calls it will block until the thread in the subroutine exits it. A more elaborate example looks like this:
784
785
786 use Thread qw(yield);
787 new Thread
788 sub sync_sub :locked {
2 perry 789 my $!CallingThread = shift @_;
1 perry 790 print
791 sub thread_sub {
792 my $ThreadID = shift @_;
793 print
794 The 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.
795
796
797 __Methods__
798
799
800 Locking an entire subroutine can sometimes be overkill,
801 especially when dealing with Perl objects. When calling a
802 method for an object, for example, you want to serialize
803 calls to a method, so that only one thread will be in the
804 subroutine for a particular object, but threads calling that
805 subroutine for a different object aren't blocked. The method
806 attribute indicates whether the subroutine is really a
807 method.
808
809
810 use Thread;
811 sub tester {
812 my $thrnum = shift @_;
813 my $bar = new Foo;
814 foreach (1..10) {
815 print
816 foreach my $thrnum (1..10) {
817 new Thread
818 package Foo;
819 sub new {
820 my $class = shift @_;
821 return bless [[@_], $class;
822 }
823 sub per_object :locked :method {
824 my ($class, $thrnum) = @_;
825 print
826 sub one_at_a_time :locked {
827 my ($class, $thrnum) = @_;
828 print
829 As you can see from the output (omitted for brevity; it's 800 lines) all the threads can be in ''per_object()'' simultaneously, but only one thread is ever in ''one_at_a_time()'' at once.
830
831
832 __Locking A Subroutine__
833
834
835 You can lock a subroutine as you would lock a variable.
836 Subroutine locks work the same as specifying a
837 locked attribute for the subroutine, and block all
838 access to the subroutine for other threads until the lock
839 goes out of scope. When the subroutine isn't locked, any
840 number of threads can be in it at once, and getting a lock
841 on a subroutine doesn't affect threads already in the
842 subroutine. Getting a lock on a subroutine looks like
843 this:
844
845
846 lock(
847 Simple enough. Unlike the 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(locked attribute, so make sure you're choosing the proper method to do the locking.
848
849
850 You'd choose lock(
851
852
853 package Foo;
854 use Config;
855 $Running_Threaded = 0;
856 BEGIN { $Running_Threaded = $Config{'usethreads'} }
857 sub sub1 { lock(
858 This way you can ensure single-threadedness regardless of which version of Perl you're running.
859 !!General Thread Utility Routines
860
861
862 We've covered the workhorse parts of Perl's threading
863 package, and with these tools you should be well on your way
864 to writing threaded code and packages. There are a few
865 useful little pieces that didn't really fit in anyplace
866 else.
867
868
869 __What Thread Am I In?__
870
871
872 The Thread-
873
874
875 __Thread IDs__
876
877
878 ''tid()'' is a thread object method that returns the
879 thread ID of the thread the object
880 represents. Thread IDs are integers, with the main thread in
881 a program being 0. Currently Perl assigns a unique tid to
882 every thread ever created in your program, assigning the
883 first thread to be created a tid of 1, and increasing the
884 tid by 1 for each new thread that's created.
885
886
887 __Are These Threads The Same?__
888
889
890 The ''equal()'' method takes two thread objects and
891 returns true if the objects represent the same thread, and
892 false if they don't.
893
894
895 __What Threads Are Running?__
896
897
898 Thread-
899
900
901 # Loop through all the threads
902 foreach $thr (Thread-
903 The example above is just for illustration. It isn't strictly necessary to join all the threads you create, since Perl detaches all the threads before it exits.
904 !!A Complete Example
905
906
907 Confused yet? It's time for an example program to show some
908 of the things we've covered. This program finds prime
909 numbers using threads.
910
911
912 1 #!/usr/bin/perl -w
913 2 # prime-pthread, courtesy of Tom Christiansen
914 3
915 4 use strict;
916 5
917 6 use Thread;
918 7 use Thread::Queue;
919 8
920 9 my $stream = new Thread::Queue;
921 10 my $kid = new Thread(
922 This program uses the pipeline model to generate prime numbers. Each thread in the pipeline has an input queue that feeds numbers to be checked, a prime number that it's responsible for, and an output queue that it funnels numbers that have failed the check into. If the thread has a number that's failed its check and there's no child thread, then the thread must have found a new prime number. In that case, a new child thread is created for that prime and stuck on the end of the pipeline.
923
924
925 This probably sounds a bit more confusing than it really is,
926 so lets go through this program piece by piece and see what
927 it does. (For those of you who might be trying to remember
928 exactly what a prime number is, it's a number that's only
929 evenly divisible by itself and 1)
930
931
932 The bulk of the work is done by the ''check_num()''
933 subroutine, which takes a reference to its input queue and a
934 prime number that it's responsible for. After pulling in the
935 input queue and the prime that the subroutine's checking
936 (line 20), we create a new queue (line 22) and reserve a
937 scalar for the thread that we're likely to create later
938 (line 21).
939
940
941 The while loop from lines 23 to line 31 grabs a scalar off
942 the input queue and checks against the prime this thread is
943 responsible for. Line 24 checks to see if there's a
944 remainder when we modulo the number to be checked against
945 our prime. If there is one, the number must not be evenly
946 divisible by our prime, so we need to either pass it on to
947 the next thread if we've created one (line 26) or create a
948 new thread if we haven't.
949
950
951 The new thread creation is line 29. We pass on to it a
952 reference to the queue we've created, and the prime number
953 we've found.
954
955
956 Finally, once the loop terminates (because we got a 0 or
957 undef in the queue, which serves as a note to die), we pass
958 on the notice to our child and wait for it to exit if we've
959 created a child (Lines 32 and 37).
960
961
962 Meanwhile, back in the main thread, we create a queue (line
963 9) and the initial child thread (line 10), and pre-seed it
964 with the first prime: 2. Then we queue all the numbers from
965 3 to 1000 for checking (lines 12-14), then queue a die
966 notice (line 16) and wait for the first child thread to
967 terminate (line 17). Because a child won't die until its
968 child has died, we know that we're done once we return from
969 the join.
970
971
972 That's how it works. It's pretty simple; as with many Perl
973 programs, the explanation is much longer than the
974 program.
975 !!Conclusion
976
977
978 A complete thread tutorial could fill a book (and has, many
979 times), but this should get you well on your way. The final
980 authority on how Perl's threads behave is the documentation
981 bundled with the Perl distribution, but with what we've
982 covered in this article, you should be well on your way to
983 becoming a threaded Perl expert.
984 !!Bibliography
985
986
987 Here's a short bibliography courtesy of J
988
989
990 __Introductory Texts__
991
992
993 Birrell, Andrew D. An Introduction to Programming with
994 Threads. Digital Equipment Corporation, 1989, DEC-SRC
995 Research Report #35 online as
996 http://www.research.digital.com/SRC/staff/birrell/bib.html
997 (highly recommended)
998
999
1000 Robbins, Kay. A., and Steven Robbins. Practical Unix
1001 Programming: A Guide to Concurrency, Communication, and
1002 Multithreading. Prentice-Hall, 1996.
1003
1004
1005 Lewis, Bill, and Daniel J. Berg. Multithreaded Programming
1006 with Pthreads. Prentice Hall, 1997, ISBN
1007 0-13-443698-9 (a well-written introduction to
1008 threads).
1009
1010
1011 Nelson, Greg (editor). Systems Programming with Modula-3.
1012 Prentice Hall, 1991, ISBN
1013 0-13-590464-1.
1014
1015
1016 Nichols, Bradford, Dick Buttlar, and Jacqueline Proulx
1017 Farrell. Pthreads Programming. O'Reilly
1018 ISBN 156592-115-1 (covers
1019 POSIX threads).
1020
1021
1022 __OS-Related References__
1023
1024
1025 Boykin, Joseph, David Kirschen, Alan Langerman, and Susan
2 perry 1026 !LoVerso. Programming under Mach. Addison-Wesley, 1994,
1 perry 1027 ISBN 0-201-52739-1.
1028
1029
1030 Tanenbaum, Andrew S. Distributed Operating Systems. Prentice
1031 Hall, 1995, ISBN 0-13-219908-4 (great
1032 textbook).
1033
1034
1035 Silberschatz, Abraham, and Peter B. Galvin. Operating System
1036 Concepts, 4th ed. Addison-Wesley, 1995, ISBN
1037 0-201-59292-4
1038
1039
1040 __Other References__
1041
1042
1043 Arnold, Ken and James Gosling. The Java Programming
1044 Language, 2nd ed. Addison-Wesley, 1998, ISBN
1045 0-201-31006-6.
1046
1047
1048 Le Sergent, T. and B. Berthomieu. ``Incremental
2 perry 1049 !MultiThreaded Garbage Collection on Virtually Shared Memory
1 perry 1050 Architectures'' in Memory Management: Proc. of the
1051 International Workshop IWMM 92, St. Malo,
1052 France, September 1992, Yves Bekkers and Jacques Cohen, eds.
1053 Springer, 1992, ISBN 3540-55940-X (real-life
1054 thread applications).
1055 !!Acknowledgements
1056
1057
1058 Thanks (in no particular order) to Chaim Frenkel, Steve
1059 Fink, Gurusamy Sarathy, Ilya Zakharevich, Benjamin Sugars,
1060 J
1061 !!AUTHOR
1062
1063
1064 Dan Sugalski
1065 !!Copyrights
1066
1067
1068 This article originally appeared in The Perl Journal #10,
1069 and is copyright 1998 The Perl Journal. It appears courtesy
1070 of Jon Orwant and The Perl Journal. This document may be
1071 distributed under the same terms as Perl
1072 itself.
1073 ----
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.