perlthrtut.pod

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

    $thr->detach();   # Now we officially don't care any more

    sleep(15);        # Let thread run for awhile

    sub sub1 {
        $a = 0;
        while (1) {
            $a++;
            print("\$a is $a\n");
            sleep(1);
        }
    }

Once a thread is detached, it may not be joined, and any return data
that it might have produced (if it was done and waiting for a join) is
lost.

C<detach()> can also be called as a class method to allow a thread to
detach itself:

    use threads;

    my $thr = threads->create(\&sub1);

    sub sub1 {
        threads->detach();
        # Do more work
    }

=head2 Process and Thread Termination

With threads one must be careful to make sure they all have a chance to
run to completion, assuming that is what you want.

An action that terminates a process will terminate I<all> running
threads.  die() and exit() have this property,
and perl does an exit when the main thread exits,
perhaps implicitly by falling off the end of your code,
even if that's not what you want.

As an example of this case, this code prints the message
"Perl exited with active threads: 2 running and unjoined":

    use threads;
    my $thr1 = threads->new(\&thrsub, "test1");
    my $thr2 = threads->new(\&thrsub, "test2");
    sub thrsub {
       my ($message) = @_;
       sleep 1;
       print "thread $message\n";
    }

But when the following lines are added at the end:

    $thr1->join;
    $thr2->join;

it prints two lines of output, a perhaps more useful outcome.

=head1 Threads And Data

Now that we've covered the basics of threads, it's time for our next
topic: Data.  Threading introduces a couple of complications to data
access that non-threaded programs never need to worry about.

=head2 Shared And Unshared Data

The biggest difference between Perl I<ithreads> and the old 5.005 style
threading, or for that matter, to most other threading systems out there,
is that by default, no data is shared. When a new Perl thread is created,
all the data associated with the current thread is copied to the new
thread, and is subsequently private to that new thread!
This is similar in feel to what happens when a UNIX process forks,
except that in this case, the data is just copied to a different part of
memory within the same process rather than a real fork taking place.

To make use of threading, however, one usually wants the threads to share
at least some data between themselves. This is done with the
L<threads::shared> module and the C<:shared> attribute:

    use threads;
    use threads::shared;

    my $foo :shared = 1;
    my $bar = 1;
    threads->create(sub { $foo++; $bar++; })->join();

    print("$foo\n");  # Prints 2 since $foo is shared
    print("$bar\n");  # Prints 1 since $bar is not shared

In the case of a shared array, all the array's elements are shared, and for
a shared hash, all the keys and values are shared. This places
restrictions on what may be assigned to shared array and hash elements: only
simple values or references to shared variables are allowed - this is
so that a private variable can't accidentally become shared. A bad
assignment will cause the thread to die. For example:

    use threads;
    use threads::shared;

    my $var          = 1;
    my $svar :shared = 2;
    my %hash :shared;

    ... create some threads ...

    $hash{a} = 1;       # All threads see exists($hash{a}) and $hash{a} == 1
    $hash{a} = $var;    # okay - copy-by-value: same effect as previous
    $hash{a} = $svar;   # okay - copy-by-value: same effect as previous
    $hash{a} = \$svar;  # okay - a reference to a shared variable
    $hash{a} = \$var;   # This will die
    delete($hash{a});   # okay - all threads will see !exists($hash{a})

Note that a shared variable guarantees that if two or more threads try to
modify it at the same time, the internal state of the variable will not
become corrupted. However, there are no guarantees beyond this, as
explained in the next section.

=head2 Thread Pitfalls: Races

While threads bring a new set of useful tools, they also bring a
number of pitfalls.  One pitfall is the race condition:

    use threads;
    use threads::shared;

    my $a :shared = 1;
    my $thr1 = threads->create(\&sub1);
    my $thr2 = threads->create(\&sub2);

    $thr1->join;
    $thr2->join;
    print("$a\n");

    sub sub1 { my $foo = $a; $a = $foo + 1; }
    sub sub2 { my $bar = $a; $a = $bar + 1; }

What do you think C<$a> will be? The answer, unfortunately, is I<it
depends>. Both C<sub1()> and C<sub2()> access the global variable C<$a>, once
to read and once to write.  Depending on factors ranging from your
thread implementation's scheduling algorithm to the phase of the moon,
C<$a> can be 2 or 3.

Race conditions are caused by unsynchronized access to shared
data.  Without explicit synchronization, there's no way to be sure that
nothing has happened to the shared data between the time you access it
and the time you update it.  Even this simple code fragment has the
possibility of error:

    use threads;
    my $a :shared = 2;
    my $b :shared;
    my $c :shared;
    my $thr1 = threads->create(sub { $b = $a; $a = $b + 1; });
    my $thr2 = threads->create(sub { $c = $a; $a = $c + 1; });
    $thr1->join;
    $thr2->join;

Two threads both access C<$a>.  Each thread can potentially be interrupted
at any point, or be executed in any order.  At the end, C<$a> could be 3
or 4, and both C<$b> and C<$c> could be 2 or 3.

Even C<$a += 5> or C<$a++> are not guaranteed to be atomic.

Whenever your program accesses data or resources that can be accessed
by other threads, you must take steps to coordinate access or risk
data inconsistency and race conditions. Note that Perl will protect its
internals from your race conditions, but it won't protect you from you.

=head1 Synchronization and control

Perl provides a number of mechanisms to coordinate the interactions
between themselves and their data, to avoid race conditions and the like.
Some of these are designed to resemble the common techniques used in thread
libraries such as C<pthreads>; others are Perl-specific. Often, the
standard techniques are clumsy and difficult to get right (such as
condition waits). Where possible, it is usually easier to use Perlish
techniques such as queues, which remove some of the hard work involved.

=head2 Controlling access: lock()

The C<lock()> function takes a shared variable and puts a lock on it.
No other thread may lock the variable until the variable is unlocked
by the thread holding the lock. Unlocking happens automatically
when the locking thread exits the block that contains the call to the
C<lock()> function.  Using C<lock()> is straightforward: This example has
several threads doing some calculations in parallel, and occasionally
updating a running total:

    use threads;
    use threads::shared;

    my $total :shared = 0;

    sub calc {
        while (1) {
            my $result;
            # (... do some calculations and set $result ...)
            {
                lock($total);  # Block until we obtain the lock
                $total += $result;
            } # Lock implicitly released at end of scope
            last if $result == 0;
        }
    }

    my $thr1 = threads->create(\&calc);
    my $thr2 = threads->create(\&calc);
    my $thr3 = threads->create(\&calc);
    $thr1->join();
    $thr2->join();
    $thr3->join();
    print("total=$total\n");

C<lock()> blocks the thread until the variable being locked is
available.  When C<lock()> returns, your thread can be sure that no other
thread can lock that variable until the block containing the
lock exits.

It's important to note that locks don't prevent access to the variable
in question, only lock attempts.  This is in keeping with Perl's
longstanding tradition of courteous programming, and the advisory file
locking that C<flock()> gives you.

You may lock arrays and hashes as well as scalars.  Locking an array,
though, will not block subsequent locks on array elements, just lock
attempts on the array itself.

Locks are recursive, which means it's okay for a thread to
lock a variable more than once.  The lock will last until the outermost
C<lock()> on the variable goes out of scope. For example:

    my $x :shared;
    doit();

    sub doit {
        {
            {
                lock($x); # Wait for lock
                lock($x); # NOOP - we already have the lock
                {
                    lock($x); # NOOP
                    {
                        lock($x); # NOOP
                        lockit_some_more();
                    }
                }
            } # *** Implicit unlock here ***
        }
    }

    sub lockit_some_more {
        lock($x); # NOOP
    } # Nothing happens here

Note that there is no C<unlock()> function - the only way to unlock a
variable is to allow it to go out of scope.

A lock can either be used to guard the data contained within the variable
being locked, or it can be used to guard something else, like a section
of code. In this latter case, the variable in question does not hold any
useful data, and exists only for the purpose of being locked. In this
respect, the variable behaves like the mutexes and basic semaphores of
traditional thread libraries.

=head2 A Thread Pitfall: Deadlocks

Locks are a handy tool to synchronize access to data, and using them
properly is the key to safe shared data.  Unfortunately, locks aren't
without their dangers, especially when multiple locks are involved.
Consider the following code:

    use threads;

    my $a :shared = 4;
    my $b :shared = 'foo';
    my $thr1 = threads->create(sub {
        lock($a);
        sleep(20);
        lock($b);
    });
    my $thr2 = threads->create(sub {
        lock($b);
        sleep(20);
        lock($a);
    });

This program will probably hang until you kill it.  The only way it
won't hang is if one of the two threads acquires both locks
first.  A guaranteed-to-hang version is more complicated, but the
principle is the same.

The first thread will grab a lock on C<$a>, then, after a pause during which
the second thread has probably had time to do some work, try to grab a
lock on C<$b>.  Meanwhile, the second thread grabs a lock on C<$b>, then later
tries to grab a lock on C<$a>.  The second lock attempt for both threads will