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