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