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