perlthrtut.pod

视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.

the thread must have found a new prime number.  In that case, a new
child thread is created for that prime and stuck on the end of the
pipeline.

This probably sounds a bit more confusing than it really is, so let's
go through this program piece by piece and see what it does.  (For
those of you who might be trying to remember exactly what a prime
number is, it's a number that's only evenly divisible by itself and 1.)

The bulk of the work is done by the C<check_num()> subroutine, which
takes a reference to its input queue and a prime number that it's
responsible for.  After pulling in the input queue and the prime that
the subroutine is checking (line 20), we create a new queue (line 22)
and reserve a scalar for the thread that we're likely to create later
(line 21).

The while loop from lines 23 to line 31 grabs a scalar off the input
queue and checks against the prime this thread is responsible
for.  Line 24 checks to see if there's a remainder when we divide the
number to be checked by our prime.  If there is one, the number
must not be evenly divisible by our prime, so we need to either pass
it on to the next thread if we've created one (line 26) or create a
new thread if we haven't.

The new thread creation is line 29.  We pass on to it a reference to
the queue we've created, and the prime number we've found.

Finally, once the loop terminates (because we got a 0 or C<undef> in the
queue, which serves as a note to terminate), we pass on the notice to our
child and wait for it to exit if we've created a child (lines 32 and
35).

Meanwhile, back in the main thread, we first create a queue (line 10) and
queue up all the numbers from 3 to 1000 for checking (lines 11-13),
plus a termination notice (line 14).  Then we create the initial child
threads (line 16), passing it the queue and the first prime: 2.  Finally,
we wait for the first child thread to terminate (line 17).  Because a
child won't terminate until its child has terminated, we know that we're
done once we return from the C<join()>.

That's how it works.  It's pretty simple; as with many Perl programs,
the explanation is much longer than the program.

=head1 Different implementations of threads

Some background on thread implementations from the operating system
viewpoint.  There are three basic categories of threads: user-mode threads,
kernel threads, and multiprocessor kernel threads.

User-mode threads are threads that live entirely within a program and
its libraries.  In this model, the OS knows nothing about threads.  As
far as it's concerned, your process is just a process.

This is the easiest way to implement threads, and the way most OSes
start.  The big disadvantage is that, since the OS knows nothing about
threads, if one thread blocks they all do.  Typical blocking activities
include most system calls, most I/O, and things like C<sleep()>.

Kernel threads are the next step in thread evolution.  The OS knows
about kernel threads, and makes allowances for them.  The main
difference between a kernel thread and a user-mode thread is
blocking.  With kernel threads, things that block a single thread don't
block other threads.  This is not the case with user-mode threads,
where the kernel blocks at the process level and not the thread level.

This is a big step forward, and can give a threaded program quite a
performance boost over non-threaded programs.  Threads that block
performing I/O, for example, won't block threads that are doing other
things.  Each process still has only one thread running at once,
though, regardless of how many CPUs a system might have.

Since kernel threading can interrupt a thread at any time, they will
uncover some of the implicit locking assumptions you may make in your
program.  For example, something as simple as C<$a = $a + 2> can behave
unpredictably with kernel threads if C<$a> is visible to other
threads, as another thread may have changed C<$a> between the time it
was fetched on the right hand side and the time the new value is
stored.

Multiprocessor kernel threads are the final step in thread
support.  With multiprocessor kernel threads on a machine with multiple
CPUs, the OS may schedule two or more threads to run simultaneously on
different CPUs.

This can give a serious performance boost to your threaded program,
since more than one thread will be executing at the same time.  As a
tradeoff, though, any of those nagging synchronization issues that
might not have shown with basic kernel threads will appear with a
vengeance.

In addition to the different levels of OS involvement in threads,
different OSes (and different thread implementations for a particular
OS) allocate CPU cycles to threads in different ways.

Cooperative multitasking systems have running threads give up control
if one of two things happen.  If a thread calls a yield function, it
gives up control.  It also gives up control if the thread does
something that would cause it to block, such as perform I/O.  In a
cooperative multitasking implementation, one thread can starve all the
others for CPU time if it so chooses.

Preemptive multitasking systems interrupt threads at regular intervals
while the system decides which thread should run next.  In a preemptive
multitasking system, one thread usually won't monopolize the CPU.

On some systems, there can be cooperative and preemptive threads
running simultaneously. (Threads running with realtime priorities
often behave cooperatively, for example, while threads running at
normal priorities behave preemptively.)

Most modern operating systems support preemptive multitasking nowadays.

=head1 Performance considerations

The main thing to bear in mind when comparing Perl's I<ithreads> to other threading
models is the fact that for each new thread created, a complete copy of
all the variables and data of the parent thread has to be taken. Thus,
thread creation can be quite expensive, both in terms of memory usage and
time spent in creation. The ideal way to reduce these costs is to have a
relatively short number of long-lived threads, all created fairly early
on -- before the base thread has accumulated too much data. Of course, this
may not always be possible, so compromises have to be made. However, after
a thread has been created, its performance and extra memory usage should
be little different than ordinary code.

Also note that under the current implementation, shared variables
use a little more memory and are a little slower than ordinary variables.

=head1 Process-scope Changes

Note that while threads themselves are separate execution threads and
Perl data is thread-private unless explicitly shared, the threads can
affect process-scope state, affecting all the threads.

The most common example of this is changing the current working
directory using C<chdir()>.  One thread calls C<chdir()>, and the working
directory of all the threads changes.

Even more drastic example of a process-scope change is C<chroot()>:
the root directory of all the threads changes, and no thread can
undo it (as opposed to C<chdir()>).

Further examples of process-scope changes include C<umask()> and
changing uids and gids.

Thinking of mixing C<fork()> and threads?  Please lie down and wait
until the feeling passes.  Be aware that the semantics of C<fork()> vary
between platforms.  For example, some UNIX systems copy all the current
threads into the child process, while others only copy the thread that
called C<fork()>. You have been warned!

Similarly, mixing signals and threads may be problematic.
Implementations are platform-dependent, and even the POSIX
semantics may not be what you expect (and Perl doesn't even
give you the full POSIX API).  For example, there is no way to
guarantee that a signal sent to a multi-threaded Perl application
will get intercepted by any particular thread.  (However, a recently
added feature does provide the capability to send signals between
threads.  See L<threads/"THREAD SIGNALLING> for more details.)

=head1 Thread-Safety of System Libraries

Whether various library calls are thread-safe is outside the control
of Perl.  Calls often suffering from not being thread-safe include:
C<localtime()>, C<gmtime()>,  functions fetching user, group and
network information (such as C<getgrent()>, C<gethostent()>,
C<getnetent()> and so on), C<readdir()>,
C<rand()>, and C<srand()> -- in general, calls that depend on some global
external state.

If the system Perl is compiled in has thread-safe variants of such
calls, they will be used.  Beyond that, Perl is at the mercy of
the thread-safety or -unsafety of the calls.  Please consult your
C library call documentation.

On some platforms the thread-safe library interfaces may fail if the
result buffer is too small (for example the user group databases may
be rather large, and the reentrant interfaces may have to carry around
a full snapshot of those databases).  Perl will start with a small
buffer, but keep retrying and growing the result buffer
until the result fits.  If this limitless growing sounds bad for
security or memory consumption reasons you can recompile Perl with
C<PERL_REENTRANT_MAXSIZE> defined to the maximum number of bytes you will
allow.

=head1 Conclusion

A complete thread tutorial could fill a book (and has, many times),
but with what we've covered in this introduction, you should be well
on your way to becoming a threaded Perl expert.

=head1 SEE ALSO

Annotated POD for L<threads>:
L<http://annocpan.org/?mode=search&field=Module&name=threads>

Lastest version of L<threads> on CPAN:
L<http://search.cpan.org/search?module=threads>

Annotated POD for L<threads::shared>:
L<http://annocpan.org/?mode=search&field=Module&name=threads%3A%3Ashared>

Lastest version of L<threads::shared> on CPAN:
L<http://search.cpan.org/search?module=threads%3A%3Ashared>

Perl threads mailing list:
L<http://lists.cpan.org/showlist.cgi?name=iThreads>

=head1 Bibliography

Here's a short bibliography courtesy of J黵gen Christoffel:

=head2 Introductory Texts

Birrell, Andrew D. An Introduction to Programming with
Threads. Digital Equipment Corporation, 1989, DEC-SRC Research Report
#35 online as
http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstracts/src-rr-035.html
(highly recommended)

Robbins, Kay. A., and Steven Robbins. Practical Unix Programming: A
Guide to Concurrency, Communication, and
Multithreading. Prentice-Hall, 1996.

Lewis, Bill, and Daniel J. Berg. Multithreaded Programming with
Pthreads. Prentice Hall, 1997, ISBN 0-13-443698-9 (a well-written
introduction to threads).

Nelson, Greg (editor). Systems Programming with Modula-3.  Prentice
Hall, 1991, ISBN 0-13-590464-1.

Nichols, Bradford, Dick Buttlar, and Jacqueline Proulx Farrell.
Pthreads Programming. O'Reilly & Associates, 1996, ISBN 156592-115-1
(covers POSIX threads).

=head2 OS-Related References

Boykin, Joseph, David Kirschen, Alan Langerman, and Susan
LoVerso. Programming under Mach. Addison-Wesley, 1994, ISBN
0-201-52739-1.

Tanenbaum, Andrew S. Distributed Operating Systems. Prentice Hall,
1995, ISBN 0-13-219908-4 (great textbook).

Silberschatz, Abraham, and Peter B. Galvin. Operating System Concepts,
4th ed. Addison-Wesley, 1995, ISBN 0-201-59292-4

=head2 Other References

Arnold, Ken and James Gosling. The Java Programming Language, 2nd
ed. Addison-Wesley, 1998, ISBN 0-201-31006-6.

comp.programming.threads FAQ,
L<http://www.serpentine.com/~bos/threads-faq/>

Le Sergent, T. and B. Berthomieu. "Incremental MultiThreaded Garbage
Collection on Virtually Shared Memory Architectures" in Memory
Management: Proc. of the International Workshop IWMM 92, St. Malo,
France, September 1992, Yves Bekkers and Jacques Cohen, eds. Springer,
1992, ISBN 3540-55940-X (real-life thread applications).

Artur Bergman, "Where Wizards Fear To Tread", June 11, 2002,
L<http://www.perl.com/pub/a/2002/06/11/threads.html>

=head1 Acknowledgements

Thanks (in no particular order) to Chaim Frenkel, Steve Fink, Gurusamy
Sarathy, Ilya Zakharevich, Benjamin Sugars, J黵gen Christoffel, Joshua
Pritikin, and Alan Burlison, for their help in reality-checking and
polishing this article.  Big thanks to Tom Christiansen for his rewrite
of the prime number generator.

=head1 AUTHOR

Dan Sugalski E<lt>[e-mail]<gt>

Slightly modified by Arthur Bergman to fit the new thread model/module.

Reworked slightly by J鰎g Walter E<lt>[e-mail]<gt> to be more concise
about thread-safety of Perl code.

Rearranged slightly by Elizabeth Mattijsen E<lt>[e-mail]<gt> to put
less emphasis on yield().

=head1 Copyrights

The original version of this article originally appeared in The Perl
Journal #10, and is copyright 1998 The Perl Journal. It appears courtesy
of Jon Orwant and The Perl Journal.  This document may be distributed
under the same terms as Perl itself.

=cut