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