Commit | Line | Data |
---|---|---|
49781f4a AB |
1 | =encoding utf8 |
2 | ||
2605996a JH |
3 | =head1 NAME |
4 | ||
2ad6cdcf | 5 | perlthrtut - Tutorial on threads in Perl |
2605996a JH |
6 | |
7 | =head1 DESCRIPTION | |
8 | ||
2ad6cdcf | 9 | This tutorial describes the use of Perl interpreter threads (sometimes |
b6d2d446 | 10 | referred to as I<ithreads>). In this |
2ad6cdcf RGS |
11 | model, each thread runs in its own Perl interpreter, and any data sharing |
12 | between threads must be explicit. The user-level interface for I<ithreads> | |
13 | uses the L<threads> class. | |
9316ed2f | 14 | |
47f9f84c | 15 | B<NOTE>: There was another older Perl threading flavor called the 5.005 model |
4bc74966 | 16 | that used the L<threads> class. This old model was known to have problems, is |
47f9f84c | 17 | deprecated, and was removed for release 5.10. You are |
2ad6cdcf RGS |
18 | strongly encouraged to migrate any existing 5.005 threads code to the new |
19 | model as soon as possible. | |
2a4bf773 | 20 | |
53d7eaa8 | 21 | You can see which (or neither) threading flavour you have by |
6eded8f3 | 22 | running C<perl -V> and looking at the C<Platform> section. |
53d7eaa8 JH |
23 | If you have C<useithreads=define> you have ithreads, if you |
24 | have C<use5005threads=define> you have 5.005 threads. | |
25 | If you have neither, you don't have any thread support built in. | |
26 | If you have both, you are in trouble. | |
2605996a | 27 | |
2ad6cdcf RGS |
28 | The L<threads> and L<threads::shared> modules are included in the core Perl |
29 | distribution. Additionally, they are maintained as a separate modules on | |
30 | CPAN, so you can check there for any updates. | |
2605996a | 31 | |
c975c451 AB |
32 | =head1 What Is A Thread Anyway? |
33 | ||
34 | A thread is a flow of control through a program with a single | |
35 | execution point. | |
36 | ||
37 | Sounds an awful lot like a process, doesn't it? Well, it should. | |
38 | Threads are one of the pieces of a process. Every process has at least | |
39 | one thread and, up until now, every process running Perl had only one | |
40 | thread. With 5.8, though, you can create extra threads. We're going | |
41 | to show you how, when, and why. | |
42 | ||
43 | =head1 Threaded Program Models | |
44 | ||
45 | There are three basic ways that you can structure a threaded | |
46 | program. Which model you choose depends on what you need your program | |
2ad6cdcf | 47 | to do. For many non-trivial threaded programs, you'll need to choose |
c975c451 AB |
48 | different models for different pieces of your program. |
49 | ||
50 | =head2 Boss/Worker | |
51 | ||
2ad6cdcf RGS |
52 | The boss/worker model usually has one I<boss> thread and one or more |
53 | I<worker> threads. The boss thread gathers or generates tasks that need | |
c975c451 AB |
54 | to be done, then parcels those tasks out to the appropriate worker |
55 | thread. | |
56 | ||
57 | This model is common in GUI and server programs, where a main thread | |
58 | waits for some event and then passes that event to the appropriate | |
59 | worker threads for processing. Once the event has been passed on, the | |
60 | boss thread goes back to waiting for another event. | |
61 | ||
62 | The boss thread does relatively little work. While tasks aren't | |
63 | necessarily performed faster than with any other method, it tends to | |
64 | have the best user-response times. | |
65 | ||
66 | =head2 Work Crew | |
67 | ||
68 | In the work crew model, several threads are created that do | |
69 | essentially the same thing to different pieces of data. It closely | |
70 | mirrors classical parallel processing and vector processors, where a | |
71 | large array of processors do the exact same thing to many pieces of | |
72 | data. | |
73 | ||
74 | This model is particularly useful if the system running the program | |
75 | will distribute multiple threads across different processors. It can | |
76 | also be useful in ray tracing or rendering engines, where the | |
77 | individual threads can pass on interim results to give the user visual | |
78 | feedback. | |
79 | ||
80 | =head2 Pipeline | |
81 | ||
82 | The pipeline model divides up a task into a series of steps, and | |
83 | passes the results of one step on to the thread processing the | |
84 | next. Each thread does one thing to each piece of data and passes the | |
85 | results to the next thread in line. | |
86 | ||
87 | This model makes the most sense if you have multiple processors so two | |
88 | or more threads will be executing in parallel, though it can often | |
89 | make sense in other contexts as well. It tends to keep the individual | |
90 | tasks small and simple, as well as allowing some parts of the pipeline | |
91 | to block (on I/O or system calls, for example) while other parts keep | |
92 | going. If you're running different parts of the pipeline on different | |
93 | processors you may also take advantage of the caches on each | |
94 | processor. | |
95 | ||
96 | This model is also handy for a form of recursive programming where, | |
97 | rather than having a subroutine call itself, it instead creates | |
98 | another thread. Prime and Fibonacci generators both map well to this | |
99 | form of the pipeline model. (A version of a prime number generator is | |
100 | presented later on.) | |
101 | ||
bfce6503 | 102 | =head1 What kind of threads are Perl threads? |
c975c451 AB |
103 | |
104 | If you have experience with other thread implementations, you might | |
105 | find that things aren't quite what you expect. It's very important to | |
2ad6cdcf RGS |
106 | remember when dealing with Perl threads that I<Perl Threads Are Not X |
107 | Threads> for all values of X. They aren't POSIX threads, or | |
c975c451 AB |
108 | DecThreads, or Java's Green threads, or Win32 threads. There are |
109 | similarities, and the broad concepts are the same, but if you start | |
110 | looking for implementation details you're going to be either | |
111 | disappointed or confused. Possibly both. | |
112 | ||
113 | This is not to say that Perl threads are completely different from | |
ac036724 | 114 | everything that's ever come before. They're not. Perl's threading |
c975c451 AB |
115 | model owes a lot to other thread models, especially POSIX. Just as |
116 | Perl is not C, though, Perl threads are not POSIX threads. So if you | |
117 | find yourself looking for mutexes, or thread priorities, it's time to | |
118 | step back a bit and think about what you want to do and how Perl can | |
119 | do it. | |
120 | ||
2ad6cdcf | 121 | However, it is important to remember that Perl threads cannot magically |
8efd9ba4 | 122 | do things unless your operating system's threads allow it. So if your |
2ad6cdcf | 123 | system blocks the entire process on C<sleep()>, Perl usually will, as well. |
c975c451 | 124 | |
2ad6cdcf | 125 | B<Perl Threads Are Different.> |
9316ed2f | 126 | |
cf5baa48 | 127 | =head1 Thread-Safe Modules |
c975c451 | 128 | |
cf5baa48 | 129 | The addition of threads has changed Perl's internals |
c975c451 | 130 | substantially. There are implications for people who write |
2ad6cdcf | 131 | modules with XS code or external libraries. However, since Perl data is |
cf5baa48 JH |
132 | not shared among threads by default, Perl modules stand a high chance of |
133 | being thread-safe or can be made thread-safe easily. Modules that are not | |
134 | tagged as thread-safe should be tested or code reviewed before being used | |
135 | in production code. | |
c975c451 AB |
136 | |
137 | Not all modules that you might use are thread-safe, and you should | |
138 | always assume a module is unsafe unless the documentation says | |
139 | otherwise. This includes modules that are distributed as part of the | |
2ad6cdcf | 140 | core. Threads are a relatively new feature, and even some of the standard |
bfce6503 | 141 | modules aren't thread-safe. |
c975c451 | 142 | |
cf5baa48 | 143 | Even if a module is thread-safe, it doesn't mean that the module is optimized |
6eded8f3 SG |
144 | to work well with threads. A module could possibly be rewritten to utilize |
145 | the new features in threaded Perl to increase performance in a threaded | |
146 | environment. | |
c975c451 AB |
147 | |
148 | If you're using a module that's not thread-safe for some reason, you | |
cf5baa48 JH |
149 | can protect yourself by using it from one, and only one thread at all. |
150 | If you need multiple threads to access such a module, you can use semaphores and | |
151 | lots of programming discipline to control access to it. Semaphores | |
152 | are covered in L</"Basic semaphores">. | |
9316ed2f | 153 | |
cf5baa48 | 154 | See also L</"Thread-Safety of System Libraries">. |
c975c451 AB |
155 | |
156 | =head1 Thread Basics | |
157 | ||
2ad6cdcf RGS |
158 | The L<threads> module provides the basic functions you need to write |
159 | threaded programs. In the following sections, we'll cover the basics, | |
c975c451 AB |
160 | showing you what you need to do to create a threaded program. After |
161 | that, we'll go over some of the features of the L<threads> module that | |
162 | make threaded programming easier. | |
163 | ||
164 | =head2 Basic Thread Support | |
165 | ||
ac036724 | 166 | Thread support is a Perl compile-time option. It's something that's |
c975c451 AB |
167 | turned on or off when Perl is built at your site, rather than when |
168 | your programs are compiled. If your Perl wasn't compiled with thread | |
169 | support enabled, then any attempt to use threads will fail. | |
170 | ||
c975c451 AB |
171 | Your programs can use the Config module to check whether threads are |
172 | enabled. If your program can't run without them, you can say something | |
173 | like: | |
174 | ||
2ad6cdcf | 175 | use Config; |
555bd962 BG |
176 | $Config{useithreads} or |
177 | die('Recompile Perl with threads to run this program.'); | |
c975c451 AB |
178 | |
179 | A possibly-threaded program using a possibly-threaded module might | |
180 | have code like this: | |
181 | ||
cf5baa48 JH |
182 | use Config; |
183 | use MyMod; | |
c975c451 | 184 | |
9316ed2f | 185 | BEGIN { |
cf5baa48 JH |
186 | if ($Config{useithreads}) { |
187 | # We have threads | |
188 | require MyMod_threaded; | |
2ad6cdcf | 189 | import MyMod_threaded; |
cf5baa48 | 190 | } else { |
2ad6cdcf RGS |
191 | require MyMod_unthreaded; |
192 | import MyMod_unthreaded; | |
9316ed2f | 193 | } |
cf5baa48 | 194 | } |
c975c451 AB |
195 | |
196 | Since code that runs both with and without threads is usually pretty | |
197 | messy, it's best to isolate the thread-specific code in its own | |
2ad6cdcf | 198 | module. In our example above, that's what C<MyMod_threaded> is, and it's |
c975c451 AB |
199 | only imported if we're running on a threaded Perl. |
200 | ||
8f95bfb9 EM |
201 | =head2 A Note about the Examples |
202 | ||
8f95bfb9 EM |
203 | In a real situation, care should be taken that all threads are finished |
204 | executing before the program exits. That care has B<not> been taken in these | |
2ad6cdcf | 205 | examples in the interest of simplicity. Running these examples I<as is> will |
8f95bfb9 EM |
206 | produce error messages, usually caused by the fact that there are still |
207 | threads running when the program exits. You should not be alarmed by this. | |
8f95bfb9 | 208 | |
c975c451 AB |
209 | =head2 Creating Threads |
210 | ||
2ad6cdcf | 211 | The L<threads> module provides the tools you need to create new |
9e75ef81 | 212 | threads. Like any other module, you need to tell Perl that you want to use |
2ad6cdcf | 213 | it; C<use threads;> imports all the pieces you need to create basic |
c975c451 AB |
214 | threads. |
215 | ||
2ad6cdcf | 216 | The simplest, most straightforward way to create a thread is with C<create()>: |
c975c451 | 217 | |
0b390a82 | 218 | use threads; |
c975c451 | 219 | |
2ad6cdcf | 220 | my $thr = threads->create(\&sub1); |
c975c451 | 221 | |
0b390a82 | 222 | sub sub1 { |
2ad6cdcf | 223 | print("In the thread\n"); |
c975c451 AB |
224 | } |
225 | ||
2ad6cdcf RGS |
226 | The C<create()> method takes a reference to a subroutine and creates a new |
227 | thread that starts executing in the referenced subroutine. Control | |
c975c451 AB |
228 | then passes both to the subroutine and the caller. |
229 | ||
230 | If you need to, your program can pass parameters to the subroutine as | |
231 | part of the thread startup. Just include the list of parameters as | |
2ad6cdcf | 232 | part of the C<threads-E<gt>create()> call, like this: |
c975c451 | 233 | |
0b390a82 | 234 | use threads; |
bfce6503 | 235 | |
2ad6cdcf RGS |
236 | my $Param3 = 'foo'; |
237 | my $thr1 = threads->create(\&sub1, 'Param 1', 'Param 2', $Param3); | |
238 | my @ParamList = (42, 'Hello', 3.14); | |
239 | my $thr2 = threads->create(\&sub1, @ParamList); | |
240 | my $thr3 = threads->create(\&sub1, qw(Param1 Param2 Param3)); | |
c975c451 | 241 | |
0b390a82 RGS |
242 | sub sub1 { |
243 | my @InboundParameters = @_; | |
2ad6cdcf | 244 | print("In the thread\n"); |
c3f7faac | 245 | print('Got parameters >', join('<>',@InboundParameters), "<\n"); |
c975c451 AB |
246 | } |
247 | ||
c975c451 AB |
248 | The last example illustrates another feature of threads. You can spawn |
249 | off several threads using the same subroutine. Each thread executes | |
250 | the same subroutine, but in a separate thread with a separate | |
251 | environment and potentially separate arguments. | |
252 | ||
2ad6cdcf | 253 | C<new()> is a synonym for C<create()>. |
bfce6503 | 254 | |
c975c451 AB |
255 | =head2 Waiting For A Thread To Exit |
256 | ||
257 | Since threads are also subroutines, they can return values. To wait | |
6eded8f3 | 258 | for a thread to exit and extract any values it might return, you can |
2ad6cdcf | 259 | use the C<join()> method: |
c975c451 | 260 | |
0b390a82 | 261 | use threads; |
bfce6503 | 262 | |
2ad6cdcf | 263 | my ($thr) = threads->create(\&sub1); |
c975c451 | 264 | |
2ad6cdcf RGS |
265 | my @ReturnData = $thr->join(); |
266 | print('Thread returned ', join(', ', @ReturnData), "\n"); | |
c975c451 | 267 | |
2ad6cdcf | 268 | sub sub1 { return ('Fifty-six', 'foo', 2); } |
c975c451 | 269 | |
2ad6cdcf | 270 | In the example above, the C<join()> method returns as soon as the thread |
c975c451 | 271 | ends. In addition to waiting for a thread to finish and gathering up |
2ad6cdcf | 272 | any values that the thread might have returned, C<join()> also performs |
c975c451 AB |
273 | any OS cleanup necessary for the thread. That cleanup might be |
274 | important, especially for long-running programs that spawn lots of | |
275 | threads. If you don't want the return values and don't want to wait | |
2ad6cdcf | 276 | for the thread to finish, you should call the C<detach()> method |
bfce6503 | 277 | instead, as described next. |
c975c451 | 278 | |
2ad6cdcf RGS |
279 | NOTE: In the example above, the thread returns a list, thus necessitating |
280 | that the thread creation call be made in list context (i.e., C<my ($thr)>). | |
e2c4d205 | 281 | See L<< threads/"$thr->join()" >> and L<threads/"THREAD CONTEXT"> for more |
2ad6cdcf RGS |
282 | details on thread context and return values. |
283 | ||
c975c451 AB |
284 | =head2 Ignoring A Thread |
285 | ||
2ad6cdcf | 286 | C<join()> does three things: it waits for a thread to exit, cleans up |
c975c451 AB |
287 | after it, and returns any data the thread may have produced. But what |
288 | if you're not interested in the thread's return values, and you don't | |
289 | really care when the thread finishes? All you want is for the thread | |
290 | to get cleaned up after when it's done. | |
291 | ||
2ad6cdcf RGS |
292 | In this case, you use the C<detach()> method. Once a thread is detached, |
293 | it'll run until it's finished; then Perl will clean up after it | |
c975c451 AB |
294 | automatically. |
295 | ||
0b390a82 | 296 | use threads; |
bfce6503 | 297 | |
2ad6cdcf RGS |
298 | my $thr = threads->create(\&sub1); # Spawn the thread |
299 | ||
300 | $thr->detach(); # Now we officially don't care any more | |
c975c451 | 301 | |
2ad6cdcf | 302 | sleep(15); # Let thread run for awhile |
c975c451 | 303 | |
cf5baa48 | 304 | sub sub1 { |
920aefca | 305 | my $count = 0; |
0b390a82 | 306 | while (1) { |
920aefca SF |
307 | $count++; |
308 | print("\$count is $count\n"); | |
2ad6cdcf | 309 | sleep(1); |
0b390a82 | 310 | } |
c975c451 AB |
311 | } |
312 | ||
bfce6503 DM |
313 | Once a thread is detached, it may not be joined, and any return data |
314 | that it might have produced (if it was done and waiting for a join) is | |
c975c451 AB |
315 | lost. |
316 | ||
2ad6cdcf RGS |
317 | C<detach()> can also be called as a class method to allow a thread to |
318 | detach itself: | |
319 | ||
320 | use threads; | |
321 | ||
322 | my $thr = threads->create(\&sub1); | |
323 | ||
324 | sub sub1 { | |
325 | threads->detach(); | |
326 | # Do more work | |
327 | } | |
328 | ||
2faf59db JH |
329 | =head2 Process and Thread Termination |
330 | ||
331 | With threads one must be careful to make sure they all have a chance to | |
332 | run to completion, assuming that is what you want. | |
333 | ||
334 | An action that terminates a process will terminate I<all> running | |
335 | threads. die() and exit() have this property, | |
336 | and perl does an exit when the main thread exits, | |
337 | perhaps implicitly by falling off the end of your code, | |
338 | even if that's not what you want. | |
339 | ||
340 | As an example of this case, this code prints the message | |
341 | "Perl exited with active threads: 2 running and unjoined": | |
342 | ||
343 | use threads; | |
344 | my $thr1 = threads->new(\&thrsub, "test1"); | |
345 | my $thr2 = threads->new(\&thrsub, "test2"); | |
346 | sub thrsub { | |
347 | my ($message) = @_; | |
348 | sleep 1; | |
349 | print "thread $message\n"; | |
350 | } | |
351 | ||
352 | But when the following lines are added at the end: | |
353 | ||
db6dbf6e JH |
354 | $thr1->join(); |
355 | $thr2->join(); | |
2faf59db JH |
356 | |
357 | it prints two lines of output, a perhaps more useful outcome. | |
358 | ||
c975c451 AB |
359 | =head1 Threads And Data |
360 | ||
361 | Now that we've covered the basics of threads, it's time for our next | |
2ad6cdcf | 362 | topic: Data. Threading introduces a couple of complications to data |
c975c451 AB |
363 | access that non-threaded programs never need to worry about. |
364 | ||
365 | =head2 Shared And Unshared Data | |
366 | ||
2ad6cdcf | 367 | The biggest difference between Perl I<ithreads> and the old 5.005 style |
bfce6503 | 368 | threading, or for that matter, to most other threading systems out there, |
2ad6cdcf | 369 | is that by default, no data is shared. When a new Perl thread is created, |
bfce6503 DM |
370 | all the data associated with the current thread is copied to the new |
371 | thread, and is subsequently private to that new thread! | |
e1020413 | 372 | This is similar in feel to what happens when a Unix process forks, |
bfce6503 DM |
373 | except that in this case, the data is just copied to a different part of |
374 | memory within the same process rather than a real fork taking place. | |
c975c451 | 375 | |
2ad6cdcf | 376 | To make use of threading, however, one usually wants the threads to share |
bfce6503 | 377 | at least some data between themselves. This is done with the |
2ad6cdcf | 378 | L<threads::shared> module and the C<:shared> attribute: |
bfce6503 DM |
379 | |
380 | use threads; | |
381 | use threads::shared; | |
382 | ||
2ad6cdcf | 383 | my $foo :shared = 1; |
bfce6503 | 384 | my $bar = 1; |
2ad6cdcf | 385 | threads->create(sub { $foo++; $bar++; })->join(); |
818c4caa | 386 | |
2ad6cdcf RGS |
387 | print("$foo\n"); # Prints 2 since $foo is shared |
388 | print("$bar\n"); # Prints 1 since $bar is not shared | |
bfce6503 DM |
389 | |
390 | In the case of a shared array, all the array's elements are shared, and for | |
391 | a shared hash, all the keys and values are shared. This places | |
392 | restrictions on what may be assigned to shared array and hash elements: only | |
393 | simple values or references to shared variables are allowed - this is | |
f3278b06 | 394 | so that a private variable can't accidentally become shared. A bad |
bfce6503 DM |
395 | assignment will cause the thread to die. For example: |
396 | ||
397 | use threads; | |
398 | use threads::shared; | |
399 | ||
2ad6cdcf RGS |
400 | my $var = 1; |
401 | my $svar :shared = 2; | |
402 | my %hash :shared; | |
bfce6503 DM |
403 | |
404 | ... create some threads ... | |
405 | ||
c3f7faac FC |
406 | $hash{a} = 1; # All threads see exists($hash{a}) |
407 | # and $hash{a} == 1 | |
2ad6cdcf RGS |
408 | $hash{a} = $var; # okay - copy-by-value: same effect as previous |
409 | $hash{a} = $svar; # okay - copy-by-value: same effect as previous | |
410 | $hash{a} = \$svar; # okay - a reference to a shared variable | |
411 | $hash{a} = \$var; # This will die | |
412 | delete($hash{a}); # okay - all threads will see !exists($hash{a}) | |
bfce6503 DM |
413 | |
414 | Note that a shared variable guarantees that if two or more threads try to | |
415 | modify it at the same time, the internal state of the variable will not | |
416 | become corrupted. However, there are no guarantees beyond this, as | |
417 | explained in the next section. | |
c975c451 | 418 | |
6eded8f3 | 419 | =head2 Thread Pitfalls: Races |
c975c451 AB |
420 | |
421 | While threads bring a new set of useful tools, they also bring a | |
422 | number of pitfalls. One pitfall is the race condition: | |
423 | ||
0b390a82 | 424 | use threads; |
c975c451 | 425 | use threads::shared; |
bfce6503 | 426 | |
920aefca | 427 | my $x :shared = 1; |
2ad6cdcf RGS |
428 | my $thr1 = threads->create(\&sub1); |
429 | my $thr2 = threads->create(\&sub2); | |
c975c451 | 430 | |
db6dbf6e JH |
431 | $thr1->join(); |
432 | $thr2->join(); | |
920aefca | 433 | print("$x\n"); |
c975c451 | 434 | |
920aefca SF |
435 | sub sub1 { my $foo = $x; $x = $foo + 1; } |
436 | sub sub2 { my $bar = $x; $x = $bar + 1; } | |
c975c451 | 437 | |
920aefca SF |
438 | What do you think C<$x> will be? The answer, unfortunately, is I<it |
439 | depends>. Both C<sub1()> and C<sub2()> access the global variable C<$x>, once | |
c975c451 AB |
440 | to read and once to write. Depending on factors ranging from your |
441 | thread implementation's scheduling algorithm to the phase of the moon, | |
920aefca | 442 | C<$x> can be 2 or 3. |
c975c451 AB |
443 | |
444 | Race conditions are caused by unsynchronized access to shared | |
445 | data. Without explicit synchronization, there's no way to be sure that | |
446 | nothing has happened to the shared data between the time you access it | |
447 | and the time you update it. Even this simple code fragment has the | |
448 | possibility of error: | |
449 | ||
0b390a82 | 450 | use threads; |
920aefca SF |
451 | my $x :shared = 2; |
452 | my $y :shared; | |
453 | my $z :shared; | |
454 | my $thr1 = threads->create(sub { $y = $x; $x = $y + 1; }); | |
455 | my $thr2 = threads->create(sub { $z = $x; $x = $z + 1; }); | |
db6dbf6e JH |
456 | $thr1->join(); |
457 | $thr2->join(); | |
c975c451 | 458 | |
920aefca SF |
459 | Two threads both access C<$x>. Each thread can potentially be interrupted |
460 | at any point, or be executed in any order. At the end, C<$x> could be 3 | |
461 | or 4, and both C<$y> and C<$z> could be 2 or 3. | |
c975c451 | 462 | |
920aefca | 463 | Even C<$x += 5> or C<$x++> are not guaranteed to be atomic. |
bfce6503 | 464 | |
c975c451 AB |
465 | Whenever your program accesses data or resources that can be accessed |
466 | by other threads, you must take steps to coordinate access or risk | |
bfce6503 DM |
467 | data inconsistency and race conditions. Note that Perl will protect its |
468 | internals from your race conditions, but it won't protect you from you. | |
469 | ||
f3278b06 | 470 | =head1 Synchronization and control |
bfce6503 DM |
471 | |
472 | Perl provides a number of mechanisms to coordinate the interactions | |
473 | between themselves and their data, to avoid race conditions and the like. | |
474 | Some of these are designed to resemble the common techniques used in thread | |
475 | libraries such as C<pthreads>; others are Perl-specific. Often, the | |
9e75ef81 | 476 | standard techniques are clumsy and difficult to get right (such as |
bfce6503 DM |
477 | condition waits). Where possible, it is usually easier to use Perlish |
478 | techniques such as queues, which remove some of the hard work involved. | |
c975c451 AB |
479 | |
480 | =head2 Controlling access: lock() | |
481 | ||
2ad6cdcf | 482 | The C<lock()> function takes a shared variable and puts a lock on it. |
a6d05634 | 483 | No other thread may lock the variable until the variable is unlocked |
bfce6503 | 484 | by the thread holding the lock. Unlocking happens automatically |
0b390a82 | 485 | when the locking thread exits the block that contains the call to the |
2ad6cdcf | 486 | C<lock()> function. Using C<lock()> is straightforward: This example has |
f3278b06 | 487 | several threads doing some calculations in parallel, and occasionally |
bfce6503 DM |
488 | updating a running total: |
489 | ||
490 | use threads; | |
491 | use threads::shared; | |
492 | ||
2ad6cdcf | 493 | my $total :shared = 0; |
bfce6503 DM |
494 | |
495 | sub calc { | |
2ad6cdcf RGS |
496 | while (1) { |
497 | my $result; | |
498 | # (... do some calculations and set $result ...) | |
499 | { | |
500 | lock($total); # Block until we obtain the lock | |
501 | $total += $result; | |
502 | } # Lock implicitly released at end of scope | |
503 | last if $result == 0; | |
504 | } | |
bfce6503 DM |
505 | } |
506 | ||
2ad6cdcf RGS |
507 | my $thr1 = threads->create(\&calc); |
508 | my $thr2 = threads->create(\&calc); | |
509 | my $thr3 = threads->create(\&calc); | |
510 | $thr1->join(); | |
511 | $thr2->join(); | |
512 | $thr3->join(); | |
513 | print("total=$total\n"); | |
c975c451 | 514 | |
2ad6cdcf RGS |
515 | C<lock()> blocks the thread until the variable being locked is |
516 | available. When C<lock()> returns, your thread can be sure that no other | |
0b390a82 | 517 | thread can lock that variable until the block containing the |
c975c451 AB |
518 | lock exits. |
519 | ||
520 | It's important to note that locks don't prevent access to the variable | |
521 | in question, only lock attempts. This is in keeping with Perl's | |
522 | longstanding tradition of courteous programming, and the advisory file | |
2ad6cdcf | 523 | locking that C<flock()> gives you. |
c975c451 AB |
524 | |
525 | You may lock arrays and hashes as well as scalars. Locking an array, | |
526 | though, will not block subsequent locks on array elements, just lock | |
527 | attempts on the array itself. | |
528 | ||
bfce6503 | 529 | Locks are recursive, which means it's okay for a thread to |
c975c451 | 530 | lock a variable more than once. The lock will last until the outermost |
2ad6cdcf | 531 | C<lock()> on the variable goes out of scope. For example: |
bfce6503 | 532 | |
2ad6cdcf | 533 | my $x :shared; |
bfce6503 DM |
534 | doit(); |
535 | ||
536 | sub doit { | |
2ad6cdcf RGS |
537 | { |
538 | { | |
539 | lock($x); # Wait for lock | |
540 | lock($x); # NOOP - we already have the lock | |
541 | { | |
542 | lock($x); # NOOP | |
543 | { | |
544 | lock($x); # NOOP | |
545 | lockit_some_more(); | |
546 | } | |
547 | } | |
548 | } # *** Implicit unlock here *** | |
549 | } | |
bfce6503 DM |
550 | } |
551 | ||
552 | sub lockit_some_more { | |
2ad6cdcf RGS |
553 | lock($x); # NOOP |
554 | } # Nothing happens here | |
bfce6503 | 555 | |
2ad6cdcf | 556 | Note that there is no C<unlock()> function - the only way to unlock a |
0b390a82 | 557 | variable is to allow it to go out of scope. |
bfce6503 DM |
558 | |
559 | A lock can either be used to guard the data contained within the variable | |
560 | being locked, or it can be used to guard something else, like a section | |
561 | of code. In this latter case, the variable in question does not hold any | |
562 | useful data, and exists only for the purpose of being locked. In this | |
563 | respect, the variable behaves like the mutexes and basic semaphores of | |
564 | traditional thread libraries. | |
c975c451 | 565 | |
bfce6503 | 566 | =head2 A Thread Pitfall: Deadlocks |
c975c451 | 567 | |
bfce6503 | 568 | Locks are a handy tool to synchronize access to data, and using them |
c975c451 | 569 | properly is the key to safe shared data. Unfortunately, locks aren't |
f3278b06 | 570 | without their dangers, especially when multiple locks are involved. |
bfce6503 | 571 | Consider the following code: |
c975c451 | 572 | |
0b390a82 RGS |
573 | use threads; |
574 | ||
920aefca SF |
575 | my $x :shared = 4; |
576 | my $y :shared = 'foo'; | |
2ad6cdcf | 577 | my $thr1 = threads->create(sub { |
920aefca | 578 | lock($x); |
2ad6cdcf | 579 | sleep(20); |
920aefca | 580 | lock($y); |
0b390a82 | 581 | }); |
2ad6cdcf | 582 | my $thr2 = threads->create(sub { |
920aefca | 583 | lock($y); |
2ad6cdcf | 584 | sleep(20); |
920aefca | 585 | lock($x); |
c975c451 AB |
586 | }); |
587 | ||
588 | This program will probably hang until you kill it. The only way it | |
bfce6503 | 589 | won't hang is if one of the two threads acquires both locks |
c975c451 AB |
590 | first. A guaranteed-to-hang version is more complicated, but the |
591 | principle is the same. | |
592 | ||
920aefca | 593 | The first thread will grab a lock on C<$x>, then, after a pause during which |
bfce6503 | 594 | the second thread has probably had time to do some work, try to grab a |
920aefca SF |
595 | lock on C<$y>. Meanwhile, the second thread grabs a lock on C<$y>, then later |
596 | tries to grab a lock on C<$x>. The second lock attempt for both threads will | |
bfce6503 | 597 | block, each waiting for the other to release its lock. |
c975c451 AB |
598 | |
599 | This condition is called a deadlock, and it occurs whenever two or | |
600 | more threads are trying to get locks on resources that the others | |
601 | own. Each thread will block, waiting for the other to release a lock | |
602 | on a resource. That never happens, though, since the thread with the | |
603 | resource is itself waiting for a lock to be released. | |
604 | ||
605 | There are a number of ways to handle this sort of problem. The best | |
606 | way is to always have all threads acquire locks in the exact same | |
920aefca SF |
607 | order. If, for example, you lock variables C<$x>, C<$y>, and C<$z>, always lock |
608 | C<$x> before C<$y>, and C<$y> before C<$z>. It's also best to hold on to locks for | |
c975c451 AB |
609 | as short a period of time to minimize the risks of deadlock. |
610 | ||
48b96218 | 611 | The other synchronization primitives described below can suffer from |
bfce6503 DM |
612 | similar problems. |
613 | ||
c975c451 AB |
614 | =head2 Queues: Passing Data Around |
615 | ||
616 | A queue is a special thread-safe object that lets you put data in one | |
617 | end and take it out the other without having to worry about | |
618 | synchronization issues. They're pretty straightforward, and look like | |
619 | this: | |
620 | ||
0b390a82 | 621 | use threads; |
83272a45 | 622 | use Thread::Queue; |
c975c451 | 623 | |
2ad6cdcf RGS |
624 | my $DataQueue = Thread::Queue->new(); |
625 | my $thr = threads->create(sub { | |
626 | while (my $DataElement = $DataQueue->dequeue()) { | |
627 | print("Popped $DataElement off the queue\n"); | |
0b390a82 RGS |
628 | } |
629 | }); | |
c975c451 | 630 | |
0b390a82 RGS |
631 | $DataQueue->enqueue(12); |
632 | $DataQueue->enqueue("A", "B", "C"); | |
2ad6cdcf | 633 | sleep(10); |
c975c451 | 634 | $DataQueue->enqueue(undef); |
2ad6cdcf | 635 | $thr->join(); |
c975c451 | 636 | |
2ad6cdcf RGS |
637 | You create the queue with C<Thread::Queue-E<gt>new()>. Then you can |
638 | add lists of scalars onto the end with C<enqueue()>, and pop scalars off | |
639 | the front of it with C<dequeue()>. A queue has no fixed size, and can grow | |
6eded8f3 | 640 | as needed to hold everything pushed on to it. |
c975c451 | 641 | |
2ad6cdcf | 642 | If a queue is empty, C<dequeue()> blocks until another thread enqueues |
c975c451 AB |
643 | something. This makes queues ideal for event loops and other |
644 | communications between threads. | |
645 | ||
c975c451 AB |
646 | =head2 Semaphores: Synchronizing Data Access |
647 | ||
bfce6503 | 648 | Semaphores are a kind of generic locking mechanism. In their most basic |
fa11829f | 649 | form, they behave very much like lockable scalars, except that they |
bfce6503 DM |
650 | can't hold data, and that they must be explicitly unlocked. In their |
651 | advanced form, they act like a kind of counter, and can allow multiple | |
2ad6cdcf | 652 | threads to have the I<lock> at any one time. |
2605996a | 653 | |
bfce6503 | 654 | =head2 Basic semaphores |
2605996a | 655 | |
2ad6cdcf | 656 | Semaphores have two methods, C<down()> and C<up()>: C<down()> decrements the resource |
8efd9ba4 | 657 | count, while C<up()> increments it. Calls to C<down()> will block if the |
c975c451 AB |
658 | semaphore's current count would decrement below zero. This program |
659 | gives a quick demonstration: | |
660 | ||
536bca94 | 661 | use threads; |
0b390a82 | 662 | use Thread::Semaphore; |
bfce6503 | 663 | |
2ad6cdcf RGS |
664 | my $semaphore = Thread::Semaphore->new(); |
665 | my $GlobalVariable :shared = 0; | |
2605996a | 666 | |
2ad6cdcf RGS |
667 | $thr1 = threads->create(\&sample_sub, 1); |
668 | $thr2 = threads->create(\&sample_sub, 2); | |
669 | $thr3 = threads->create(\&sample_sub, 3); | |
2605996a | 670 | |
0b390a82 | 671 | sub sample_sub { |
2ad6cdcf | 672 | my $SubNumber = shift(@_); |
0b390a82 RGS |
673 | my $TryCount = 10; |
674 | my $LocalCopy; | |
2ad6cdcf | 675 | sleep(1); |
0b390a82 | 676 | while ($TryCount--) { |
2ad6cdcf | 677 | $semaphore->down(); |
0b390a82 | 678 | $LocalCopy = $GlobalVariable; |
c3f7faac FC |
679 | print("$TryCount tries left for sub $SubNumber " |
680 | ."(\$GlobalVariable is $GlobalVariable)\n"); | |
2ad6cdcf | 681 | sleep(2); |
0b390a82 RGS |
682 | $LocalCopy++; |
683 | $GlobalVariable = $LocalCopy; | |
2ad6cdcf | 684 | $semaphore->up(); |
0b390a82 | 685 | } |
c975c451 | 686 | } |
6eded8f3 | 687 | |
2ad6cdcf RGS |
688 | $thr1->join(); |
689 | $thr2->join(); | |
690 | $thr3->join(); | |
2605996a | 691 | |
c975c451 AB |
692 | The three invocations of the subroutine all operate in sync. The |
693 | semaphore, though, makes sure that only one thread is accessing the | |
694 | global variable at once. | |
2605996a | 695 | |
bfce6503 | 696 | =head2 Advanced Semaphores |
2605996a | 697 | |
c975c451 | 698 | By default, semaphores behave like locks, letting only one thread |
2ad6cdcf | 699 | C<down()> them at a time. However, there are other uses for semaphores. |
2605996a | 700 | |
6eded8f3 | 701 | Each semaphore has a counter attached to it. By default, semaphores are |
2ad6cdcf RGS |
702 | created with the counter set to one, C<down()> decrements the counter by |
703 | one, and C<up()> increments by one. However, we can override any or all | |
6eded8f3 SG |
704 | of these defaults simply by passing in different values: |
705 | ||
706 | use threads; | |
83272a45 | 707 | use Thread::Semaphore; |
2ad6cdcf | 708 | |
83272a45 | 709 | my $semaphore = Thread::Semaphore->new(5); |
6eded8f3 SG |
710 | # Creates a semaphore with the counter set to five |
711 | ||
2ad6cdcf RGS |
712 | my $thr1 = threads->create(\&sub1); |
713 | my $thr2 = threads->create(\&sub1); | |
6eded8f3 SG |
714 | |
715 | sub sub1 { | |
716 | $semaphore->down(5); # Decrements the counter by five | |
717 | # Do stuff here | |
718 | $semaphore->up(5); # Increment the counter by five | |
719 | } | |
720 | ||
2ad6cdcf RGS |
721 | $thr1->detach(); |
722 | $thr2->detach(); | |
6eded8f3 | 723 | |
2ad6cdcf | 724 | If C<down()> attempts to decrement the counter below zero, it blocks until |
6eded8f3 | 725 | the counter is large enough. Note that while a semaphore can be created |
2ad6cdcf | 726 | with a starting count of zero, any C<up()> or C<down()> always changes the |
8efd9ba4 WL |
727 | counter by at least one, and so C<< $semaphore->down(0) >> is the same as |
728 | C<< $semaphore->down(1) >>. | |
2605996a | 729 | |
c975c451 AB |
730 | The question, of course, is why would you do something like this? Why |
731 | create a semaphore with a starting count that's not one, or why | |
c3e59998 | 732 | decrement or increment it by more than one? The answer is resource |
c975c451 AB |
733 | availability. Many resources that you want to manage access for can be |
734 | safely used by more than one thread at once. | |
2605996a | 735 | |
c975c451 AB |
736 | For example, let's take a GUI driven program. It has a semaphore that |
737 | it uses to synchronize access to the display, so only one thread is | |
738 | ever drawing at once. Handy, but of course you don't want any thread | |
739 | to start drawing until things are properly set up. In this case, you | |
740 | can create a semaphore with a counter set to zero, and up it when | |
741 | things are ready for drawing. | |
2605996a | 742 | |
c975c451 AB |
743 | Semaphores with counters greater than one are also useful for |
744 | establishing quotas. Say, for example, that you have a number of | |
745 | threads that can do I/O at once. You don't want all the threads | |
746 | reading or writing at once though, since that can potentially swamp | |
e1020413 | 747 | your I/O channels, or deplete your process's quota of filehandles. You |
c975c451 AB |
748 | can use a semaphore initialized to the number of concurrent I/O |
749 | requests (or open files) that you want at any one time, and have your | |
750 | threads quietly block and unblock themselves. | |
2605996a | 751 | |
c975c451 AB |
752 | Larger increments or decrements are handy in those cases where a |
753 | thread needs to check out or return a number of resources at once. | |
2605996a | 754 | |
8efd9ba4 | 755 | =head2 Waiting for a Condition |
bfce6503 | 756 | |
8efd9ba4 WL |
757 | The functions C<cond_wait()> and C<cond_signal()> |
758 | can be used in conjunction with locks to notify | |
bfce6503 DM |
759 | co-operating threads that a resource has become available. They are |
760 | very similar in use to the functions found in C<pthreads>. However | |
761 | for most purposes, queues are simpler to use and more intuitive. See | |
762 | L<threads::shared> for more details. | |
2605996a | 763 | |
536bca94 EM |
764 | =head2 Giving up control |
765 | ||
766 | There are times when you may find it useful to have a thread | |
767 | explicitly give up the CPU to another thread. You may be doing something | |
768 | processor-intensive and want to make sure that the user-interface thread | |
769 | gets called frequently. Regardless, there are times that you might want | |
770 | a thread to give up the processor. | |
771 | ||
2ad6cdcf RGS |
772 | Perl's threading package provides the C<yield()> function that does |
773 | this. C<yield()> is pretty straightforward, and works like this: | |
536bca94 | 774 | |
0b390a82 | 775 | use threads; |
536bca94 EM |
776 | |
777 | sub loop { | |
2ad6cdcf RGS |
778 | my $thread = shift; |
779 | my $foo = 50; | |
780 | while($foo--) { print("In thread $thread\n"); } | |
781 | threads->yield(); | |
782 | $foo = 50; | |
783 | while($foo--) { print("In thread $thread\n"); } | |
536bca94 EM |
784 | } |
785 | ||
2ad6cdcf RGS |
786 | my $thr1 = threads->create(\&loop, 'first'); |
787 | my $thr2 = threads->create(\&loop, 'second'); | |
788 | my $thr3 = threads->create(\&loop, 'third'); | |
536bca94 | 789 | |
2ad6cdcf | 790 | It is important to remember that C<yield()> is only a hint to give up the CPU, |
536bca94 EM |
791 | it depends on your hardware, OS and threading libraries what actually happens. |
792 | B<On many operating systems, yield() is a no-op.> Therefore it is important | |
793 | to note that one should not build the scheduling of the threads around | |
2ad6cdcf | 794 | C<yield()> calls. It might work on your platform but it won't work on another |
536bca94 EM |
795 | platform. |
796 | ||
c975c451 AB |
797 | =head1 General Thread Utility Routines |
798 | ||
799 | We've covered the workhorse parts of Perl's threading package, and | |
800 | with these tools you should be well on your way to writing threaded | |
801 | code and packages. There are a few useful little pieces that didn't | |
802 | really fit in anyplace else. | |
803 | ||
804 | =head2 What Thread Am I In? | |
805 | ||
2ad6cdcf | 806 | The C<threads-E<gt>self()> class method provides your program with a way to |
bfce6503 | 807 | get an object representing the thread it's currently in. You can use this |
6eded8f3 | 808 | object in the same way as the ones returned from thread creation. |
c975c451 AB |
809 | |
810 | =head2 Thread IDs | |
811 | ||
2ad6cdcf | 812 | C<tid()> is a thread object method that returns the thread ID of the |
c975c451 | 813 | thread the object represents. Thread IDs are integers, with the main |
2ad6cdcf | 814 | thread in a program being 0. Currently Perl assigns a unique TID to |
c975c451 | 815 | every thread ever created in your program, assigning the first thread |
8efd9ba4 | 816 | to be created a TID of 1, and increasing the TID by 1 for each new |
2ad6cdcf RGS |
817 | thread that's created. When used as a class method, C<threads-E<gt>tid()> |
818 | can be used by a thread to get its own TID. | |
c975c451 AB |
819 | |
820 | =head2 Are These Threads The Same? | |
821 | ||
2ad6cdcf | 822 | The C<equal()> method takes two thread objects and returns true |
c975c451 AB |
823 | if the objects represent the same thread, and false if they don't. |
824 | ||
2ad6cdcf | 825 | Thread objects also have an overloaded C<==> comparison so that you can do |
c975c451 AB |
826 | comparison on them as you would with normal objects. |
827 | ||
828 | =head2 What Threads Are Running? | |
829 | ||
2ad6cdcf | 830 | C<threads-E<gt>list()> returns a list of thread objects, one for each thread |
c975c451 | 831 | that's currently running and not detached. Handy for a number of things, |
2ad6cdcf RGS |
832 | including cleaning up at the end of your program (from the main Perl thread, |
833 | of course): | |
c975c451 | 834 | |
0b390a82 | 835 | # Loop through all the threads |
2ad6cdcf RGS |
836 | foreach my $thr (threads->list()) { |
837 | $thr->join(); | |
c975c451 AB |
838 | } |
839 | ||
bfce6503 DM |
840 | If some threads have not finished running when the main Perl thread |
841 | ends, Perl will warn you about it and die, since it is impossible for Perl | |
2ad6cdcf RGS |
842 | to clean up itself while other threads are running. |
843 | ||
844 | NOTE: The main Perl thread (thread 0) is in a I<detached> state, and so | |
845 | does not appear in the list returned by C<threads-E<gt>list()>. | |
c975c451 AB |
846 | |
847 | =head1 A Complete Example | |
848 | ||
849 | Confused yet? It's time for an example program to show some of the | |
850 | things we've covered. This program finds prime numbers using threads. | |
851 | ||
c3f7faac FC |
852 | 1 #!/usr/bin/perl |
853 | 2 # prime-pthread, courtesy of Tom Christiansen | |
854 | 3 | |
855 | 4 use strict; | |
856 | 5 use warnings; | |
857 | 6 | |
858 | 7 use threads; | |
859 | 8 use Thread::Queue; | |
860 | 9 | |
861 | 10 sub check_num { | |
862 | 11 my ($upstream, $cur_prime) = @_; | |
863 | 12 my $kid; | |
864 | 13 my $downstream = Thread::Queue->new(); | |
865 | 14 while (my $num = $upstream->dequeue()) { | |
866 | 15 next unless ($num % $cur_prime); | |
867 | 16 if ($kid) { | |
868 | 17 $downstream->enqueue($num); | |
869 | 18 } else { | |
870 | 19 print("Found prime: $num\n"); | |
871 | 20 $kid = threads->create(\&check_num, $downstream, $num); | |
872 | 21 if (! $kid) { | |
873 | 22 warn("Sorry. Ran out of threads.\n"); | |
874 | 23 last; | |
875 | 24 } | |
876 | 25 } | |
877 | 26 } | |
878 | 27 if ($kid) { | |
879 | 28 $downstream->enqueue(undef); | |
880 | 29 $kid->join(); | |
881 | 30 } | |
882 | 31 } | |
883 | 32 | |
884 | 33 my $stream = Thread::Queue->new(3..1000, undef); | |
885 | 34 check_num($stream, 2); | |
c975c451 AB |
886 | |
887 | This program uses the pipeline model to generate prime numbers. Each | |
888 | thread in the pipeline has an input queue that feeds numbers to be | |
889 | checked, a prime number that it's responsible for, and an output queue | |
9e75ef81 | 890 | into which it funnels numbers that have failed the check. If the thread |
c975c451 AB |
891 | has a number that's failed its check and there's no child thread, then |
892 | the thread must have found a new prime number. In that case, a new | |
893 | child thread is created for that prime and stuck on the end of the | |
894 | pipeline. | |
895 | ||
6eded8f3 | 896 | This probably sounds a bit more confusing than it really is, so let's |
c975c451 AB |
897 | go through this program piece by piece and see what it does. (For |
898 | those of you who might be trying to remember exactly what a prime | |
2ad6cdcf | 899 | number is, it's a number that's only evenly divisible by itself and 1.) |
c975c451 | 900 | |
2ad6cdcf | 901 | The bulk of the work is done by the C<check_num()> subroutine, which |
c975c451 AB |
902 | takes a reference to its input queue and a prime number that it's |
903 | responsible for. After pulling in the input queue and the prime that | |
db6dbf6e | 904 | the subroutine is checking (line 11), we create a new queue (line 13) |
c975c451 | 905 | and reserve a scalar for the thread that we're likely to create later |
db6dbf6e | 906 | (line 12). |
c975c451 | 907 | |
db6dbf6e | 908 | The while loop from line 14 to line 26 grabs a scalar off the input |
c975c451 | 909 | queue and checks against the prime this thread is responsible |
db6dbf6e | 910 | for. Line 15 checks to see if there's a remainder when we divide the |
c3e59998 | 911 | number to be checked by our prime. If there is one, the number |
c975c451 | 912 | must not be evenly divisible by our prime, so we need to either pass |
db6dbf6e | 913 | it on to the next thread if we've created one (line 17) or create a |
c975c451 AB |
914 | new thread if we haven't. |
915 | ||
db6dbf6e JH |
916 | The new thread creation is line 20. We pass on to it a reference to |
917 | the queue we've created, and the prime number we've found. In lines 21 | |
918 | through 24, we check to make sure that our new thread got created, and | |
919 | if not, we stop checking any remaining numbers in the queue. | |
c975c451 | 920 | |
2ad6cdcf RGS |
921 | Finally, once the loop terminates (because we got a 0 or C<undef> in the |
922 | queue, which serves as a note to terminate), we pass on the notice to our | |
db6dbf6e JH |
923 | child, and wait for it to exit if we've created a child (lines 27 and |
924 | 30). | |
925 | ||
926 | Meanwhile, back in the main thread, we first create a queue (line 33) and | |
927 | queue up all the numbers from 3 to 1000 for checking, plus a termination | |
928 | notice. Then all we have to do to get the ball rolling is pass the queue | |
929 | and the first prime to the C<check_num()> subroutine (line 34). | |
c975c451 AB |
930 | |
931 | That's how it works. It's pretty simple; as with many Perl programs, | |
932 | the explanation is much longer than the program. | |
933 | ||
536bca94 EM |
934 | =head1 Different implementations of threads |
935 | ||
936 | Some background on thread implementations from the operating system | |
937 | viewpoint. There are three basic categories of threads: user-mode threads, | |
938 | kernel threads, and multiprocessor kernel threads. | |
939 | ||
940 | User-mode threads are threads that live entirely within a program and | |
941 | its libraries. In this model, the OS knows nothing about threads. As | |
942 | far as it's concerned, your process is just a process. | |
943 | ||
944 | This is the easiest way to implement threads, and the way most OSes | |
945 | start. The big disadvantage is that, since the OS knows nothing about | |
946 | threads, if one thread blocks they all do. Typical blocking activities | |
2ad6cdcf | 947 | include most system calls, most I/O, and things like C<sleep()>. |
536bca94 EM |
948 | |
949 | Kernel threads are the next step in thread evolution. The OS knows | |
950 | about kernel threads, and makes allowances for them. The main | |
951 | difference between a kernel thread and a user-mode thread is | |
952 | blocking. With kernel threads, things that block a single thread don't | |
953 | block other threads. This is not the case with user-mode threads, | |
954 | where the kernel blocks at the process level and not the thread level. | |
955 | ||
956 | This is a big step forward, and can give a threaded program quite a | |
957 | performance boost over non-threaded programs. Threads that block | |
958 | performing I/O, for example, won't block threads that are doing other | |
959 | things. Each process still has only one thread running at once, | |
960 | though, regardless of how many CPUs a system might have. | |
961 | ||
962 | Since kernel threading can interrupt a thread at any time, they will | |
963 | uncover some of the implicit locking assumptions you may make in your | |
920aefca SF |
964 | program. For example, something as simple as C<$x = $x + 2> can behave |
965 | unpredictably with kernel threads if C<$x> is visible to other | |
966 | threads, as another thread may have changed C<$x> between the time it | |
536bca94 EM |
967 | was fetched on the right hand side and the time the new value is |
968 | stored. | |
969 | ||
970 | Multiprocessor kernel threads are the final step in thread | |
971 | support. With multiprocessor kernel threads on a machine with multiple | |
972 | CPUs, the OS may schedule two or more threads to run simultaneously on | |
973 | different CPUs. | |
974 | ||
975 | This can give a serious performance boost to your threaded program, | |
976 | since more than one thread will be executing at the same time. As a | |
977 | tradeoff, though, any of those nagging synchronization issues that | |
978 | might not have shown with basic kernel threads will appear with a | |
979 | vengeance. | |
980 | ||
981 | In addition to the different levels of OS involvement in threads, | |
982 | different OSes (and different thread implementations for a particular | |
983 | OS) allocate CPU cycles to threads in different ways. | |
984 | ||
985 | Cooperative multitasking systems have running threads give up control | |
986 | if one of two things happen. If a thread calls a yield function, it | |
987 | gives up control. It also gives up control if the thread does | |
988 | something that would cause it to block, such as perform I/O. In a | |
989 | cooperative multitasking implementation, one thread can starve all the | |
990 | others for CPU time if it so chooses. | |
991 | ||
992 | Preemptive multitasking systems interrupt threads at regular intervals | |
993 | while the system decides which thread should run next. In a preemptive | |
994 | multitasking system, one thread usually won't monopolize the CPU. | |
995 | ||
996 | On some systems, there can be cooperative and preemptive threads | |
997 | running simultaneously. (Threads running with realtime priorities | |
998 | often behave cooperatively, for example, while threads running at | |
999 | normal priorities behave preemptively.) | |
1000 | ||
1001 | Most modern operating systems support preemptive multitasking nowadays. | |
1002 | ||
bfce6503 DM |
1003 | =head1 Performance considerations |
1004 | ||
2ad6cdcf | 1005 | The main thing to bear in mind when comparing Perl's I<ithreads> to other threading |
bfce6503 | 1006 | models is the fact that for each new thread created, a complete copy of |
2ad6cdcf | 1007 | all the variables and data of the parent thread has to be taken. Thus, |
bfce6503 DM |
1008 | thread creation can be quite expensive, both in terms of memory usage and |
1009 | time spent in creation. The ideal way to reduce these costs is to have a | |
1010 | relatively short number of long-lived threads, all created fairly early | |
ac036724 | 1011 | on (before the base thread has accumulated too much data). Of course, this |
bfce6503 DM |
1012 | may not always be possible, so compromises have to be made. However, after |
1013 | a thread has been created, its performance and extra memory usage should | |
1014 | be little different than ordinary code. | |
1015 | ||
1016 | Also note that under the current implementation, shared variables | |
1017 | use a little more memory and are a little slower than ordinary variables. | |
1018 | ||
cf5baa48 JH |
1019 | =head1 Process-scope Changes |
1020 | ||
1021 | Note that while threads themselves are separate execution threads and | |
1022 | Perl data is thread-private unless explicitly shared, the threads can | |
1023 | affect process-scope state, affecting all the threads. | |
1024 | ||
1025 | The most common example of this is changing the current working | |
2ad6cdcf | 1026 | directory using C<chdir()>. One thread calls C<chdir()>, and the working |
cf5baa48 | 1027 | directory of all the threads changes. |
bdcfa4c7 | 1028 | |
2ad6cdcf | 1029 | Even more drastic example of a process-scope change is C<chroot()>: |
cf5baa48 | 1030 | the root directory of all the threads changes, and no thread can |
2ad6cdcf | 1031 | undo it (as opposed to C<chdir()>). |
cf5baa48 | 1032 | |
2ad6cdcf | 1033 | Further examples of process-scope changes include C<umask()> and |
c3e59998 | 1034 | changing uids and gids. |
cf5baa48 | 1035 | |
2ad6cdcf RGS |
1036 | Thinking of mixing C<fork()> and threads? Please lie down and wait |
1037 | until the feeling passes. Be aware that the semantics of C<fork()> vary | |
e1020413 | 1038 | between platforms. For example, some Unix systems copy all the current |
a95a5f75 | 1039 | threads into the child process, while others only copy the thread that |
2ad6cdcf | 1040 | called C<fork()>. You have been warned! |
cf5baa48 | 1041 | |
2ad6cdcf | 1042 | Similarly, mixing signals and threads may be problematic. |
b03ad8f6 JH |
1043 | Implementations are platform-dependent, and even the POSIX |
1044 | semantics may not be what you expect (and Perl doesn't even | |
2ad6cdcf RGS |
1045 | give you the full POSIX API). For example, there is no way to |
1046 | guarantee that a signal sent to a multi-threaded Perl application | |
1047 | will get intercepted by any particular thread. (However, a recently | |
1048 | added feature does provide the capability to send signals between | |
4bc74966 | 1049 | threads. See L<threads/THREAD SIGNALLING> for more details.) |
b03ad8f6 | 1050 | |
cf5baa48 JH |
1051 | =head1 Thread-Safety of System Libraries |
1052 | ||
1053 | Whether various library calls are thread-safe is outside the control | |
1054 | of Perl. Calls often suffering from not being thread-safe include: | |
8efd9ba4 WL |
1055 | C<localtime()>, C<gmtime()>, functions fetching user, group and |
1056 | network information (such as C<getgrent()>, C<gethostent()>, | |
ac036724 | 1057 | C<getnetent()> and so on), C<readdir()>, C<rand()>, and C<srand()>. In |
1058 | general, calls that depend on some global external state. | |
80bbcbc4 | 1059 | |
cf5baa48 | 1060 | If the system Perl is compiled in has thread-safe variants of such |
80bbcbc4 | 1061 | calls, they will be used. Beyond that, Perl is at the mercy of |
cf5baa48 | 1062 | the thread-safety or -unsafety of the calls. Please consult your |
80bbcbc4 JH |
1063 | C library call documentation. |
1064 | ||
af685957 JH |
1065 | On some platforms the thread-safe library interfaces may fail if the |
1066 | result buffer is too small (for example the user group databases may | |
1067 | be rather large, and the reentrant interfaces may have to carry around | |
1068 | a full snapshot of those databases). Perl will start with a small | |
1069 | buffer, but keep retrying and growing the result buffer | |
1070 | until the result fits. If this limitless growing sounds bad for | |
1071 | security or memory consumption reasons you can recompile Perl with | |
2ad6cdcf | 1072 | C<PERL_REENTRANT_MAXSIZE> defined to the maximum number of bytes you will |
af685957 | 1073 | allow. |
bdcfa4c7 | 1074 | |
c975c451 AB |
1075 | =head1 Conclusion |
1076 | ||
1077 | A complete thread tutorial could fill a book (and has, many times), | |
6eded8f3 SG |
1078 | but with what we've covered in this introduction, you should be well |
1079 | on your way to becoming a threaded Perl expert. | |
c975c451 | 1080 | |
2ad6cdcf RGS |
1081 | =head1 SEE ALSO |
1082 | ||
1083 | Annotated POD for L<threads>: | |
1084 | L<http://annocpan.org/?mode=search&field=Module&name=threads> | |
1085 | ||
c69ca1d4 | 1086 | Latest version of L<threads> on CPAN: |
2ad6cdcf RGS |
1087 | L<http://search.cpan.org/search?module=threads> |
1088 | ||
1089 | Annotated POD for L<threads::shared>: | |
1090 | L<http://annocpan.org/?mode=search&field=Module&name=threads%3A%3Ashared> | |
1091 | ||
c69ca1d4 | 1092 | Latest version of L<threads::shared> on CPAN: |
2ad6cdcf RGS |
1093 | L<http://search.cpan.org/search?module=threads%3A%3Ashared> |
1094 | ||
1095 | Perl threads mailing list: | |
7d0fb9b8 | 1096 | L<http://lists.perl.org/list/ithreads.html> |
2ad6cdcf | 1097 | |
c975c451 AB |
1098 | =head1 Bibliography |
1099 | ||
aadc0e04 | 1100 | Here's a short bibliography courtesy of Jürgen Christoffel: |
c975c451 AB |
1101 | |
1102 | =head2 Introductory Texts | |
1103 | ||
1104 | Birrell, Andrew D. An Introduction to Programming with | |
1105 | Threads. Digital Equipment Corporation, 1989, DEC-SRC Research Report | |
1106 | #35 online as | |
08d7a6b2 | 1107 | ftp://ftp.dec.com/pub/DEC/SRC/research-reports/SRC-035.pdf |
6eded8f3 | 1108 | (highly recommended) |
c975c451 AB |
1109 | |
1110 | Robbins, Kay. A., and Steven Robbins. Practical Unix Programming: A | |
1111 | Guide to Concurrency, Communication, and | |
1112 | Multithreading. Prentice-Hall, 1996. | |
1113 | ||
1114 | Lewis, Bill, and Daniel J. Berg. Multithreaded Programming with | |
1115 | Pthreads. Prentice Hall, 1997, ISBN 0-13-443698-9 (a well-written | |
1116 | introduction to threads). | |
1117 | ||
1118 | Nelson, Greg (editor). Systems Programming with Modula-3. Prentice | |
1119 | Hall, 1991, ISBN 0-13-590464-1. | |
1120 | ||
1121 | Nichols, Bradford, Dick Buttlar, and Jacqueline Proulx Farrell. | |
1122 | Pthreads Programming. O'Reilly & Associates, 1996, ISBN 156592-115-1 | |
1123 | (covers POSIX threads). | |
1124 | ||
1125 | =head2 OS-Related References | |
1126 | ||
1127 | Boykin, Joseph, David Kirschen, Alan Langerman, and Susan | |
1128 | LoVerso. Programming under Mach. Addison-Wesley, 1994, ISBN | |
1129 | 0-201-52739-1. | |
1130 | ||
1131 | Tanenbaum, Andrew S. Distributed Operating Systems. Prentice Hall, | |
1132 | 1995, ISBN 0-13-219908-4 (great textbook). | |
1133 | ||
1134 | Silberschatz, Abraham, and Peter B. Galvin. Operating System Concepts, | |
1135 | 4th ed. Addison-Wesley, 1995, ISBN 0-201-59292-4 | |
1136 | ||
1137 | =head2 Other References | |
1138 | ||
1139 | Arnold, Ken and James Gosling. The Java Programming Language, 2nd | |
1140 | ed. Addison-Wesley, 1998, ISBN 0-201-31006-6. | |
1141 | ||
b03ad8f6 JH |
1142 | comp.programming.threads FAQ, |
1143 | L<http://www.serpentine.com/~bos/threads-faq/> | |
1144 | ||
c975c451 AB |
1145 | Le Sergent, T. and B. Berthomieu. "Incremental MultiThreaded Garbage |
1146 | Collection on Virtually Shared Memory Architectures" in Memory | |
1147 | Management: Proc. of the International Workshop IWMM 92, St. Malo, | |
1148 | France, September 1992, Yves Bekkers and Jacques Cohen, eds. Springer, | |
1149 | 1992, ISBN 3540-55940-X (real-life thread applications). | |
1150 | ||
5e549d84 JH |
1151 | Artur Bergman, "Where Wizards Fear To Tread", June 11, 2002, |
1152 | L<http://www.perl.com/pub/a/2002/06/11/threads.html> | |
1153 | ||
c975c451 AB |
1154 | =head1 Acknowledgements |
1155 | ||
1156 | Thanks (in no particular order) to Chaim Frenkel, Steve Fink, Gurusamy | |
aadc0e04 | 1157 | Sarathy, Ilya Zakharevich, Benjamin Sugars, Jürgen Christoffel, Joshua |
c975c451 AB |
1158 | Pritikin, and Alan Burlison, for their help in reality-checking and |
1159 | polishing this article. Big thanks to Tom Christiansen for his rewrite | |
1160 | of the prime number generator. | |
1161 | ||
1162 | =head1 AUTHOR | |
1163 | ||
9316ed2f | 1164 | Dan Sugalski E<lt>dan@sidhe.org<gt> |
c975c451 AB |
1165 | |
1166 | Slightly modified by Arthur Bergman to fit the new thread model/module. | |
1167 | ||
e1020413 | 1168 | Reworked slightly by Jörg Walter E<lt>jwalt@cpan.org<gt> to be more concise |
2ad6cdcf | 1169 | about thread-safety of Perl code. |
cf5baa48 | 1170 | |
536bca94 EM |
1171 | Rearranged slightly by Elizabeth Mattijsen E<lt>liz@dijkmat.nl<gt> to put |
1172 | less emphasis on yield(). | |
1173 | ||
c975c451 AB |
1174 | =head1 Copyrights |
1175 | ||
bfce6503 DM |
1176 | The original version of this article originally appeared in The Perl |
1177 | Journal #10, and is copyright 1998 The Perl Journal. It appears courtesy | |
1178 | of Jon Orwant and The Perl Journal. This document may be distributed | |
1179 | under the same terms as Perl itself. | |
2605996a | 1180 | |
2ad6cdcf | 1181 | =cut |