view release on metacpan or  search on metacpan

lib/IPC/ConcurrencyLimit.pm  view on Meta::CPAN

Creates the actual lock and if successful, returns its id
(starting from 1, not 0).

Returns undef if locking was unsuccessful.
Multiple calls do not stack. They will simply return
the same lock id as long as a lock is held.

B<WARNING!> make sure the variable holding the lock remains in scope at all
times, otherwise the lock will be released and locking will become apparently
ineffective. This is the most common reason for having several concurrent
processes running when only one is expected to be alive.

=head2 release_lock

Releases the lock. Returns 1 if a lock has been
released or undef if there had been no lock to be
released.

=head2 is_locked

Returns whether we have a lock.

lib/IPC/ConcurrencyLimit/WithLatestStandby.pm  view on Meta::CPAN

This module behaves much the same as L<IPC::ConcurrencyLimit> when configured
for a single lock, with the exception of what happens when the lock is already
held by another process. Instead of simply returning false, the lock will block
and the worker will go into a "standby queue" waiting to acquire the master lock.
If the master lock is released then the next worker in the queue takes over,
and additionally workers in standby mode are managed such that older standby
workers "bow out" when they detect a newer standby worker is available to take
over waiting.  When configured and used properly you are guaranteed to get the
most recent worker "taking over" processing every time.

When using this module at any one time there may be up to four workers alive.
One master process, one primary standby, one secondary standby, and one new
standby, each one corresponding to one of four locks, numbered 0 to 3. Each
new worker starts by acquiring the rightmost lock, #3, and then tries to
"move left" by also acquiring the preceding lock, which when successful leads
to it dropping its old lock. When the worker ends up holding the master lock #0
it can do work. At the same time the holder of the primary standby lock #1
also polls to see if the secondary standby lock #2 is held. If it is then the holder
of the lock #1 exits, allowing the secondary standby lock to "move left" and
take over standby responsibility.

lib/IPC/ConcurrencyLimit/WithStandby.pm  view on Meta::CPAN

On my testing Linux, a process that showed as C<perl foo.pl> in the process
table before using this feature was shown as C<foo.pl - standby> while
in standby mode and as C<foo.pl> after getting a main worker lock.
Note the curiously stripped C<perl> prefix.

=head1 WARNING!

Make sure the variable holding the lock remains in scope at all times,
otherwise the lock will be released, resulting in process churn and potential
double work. This is the most common reason for having several concurrent
processes running when only one is expected to be alive.

=head1 AUTHOR

Steffen Mueller, C<smueller@cpan.org>

David Morel, C<david.morel@amakuru.net>

=head1 ACKNOWLEDGMENT

This module was originally developed for booking.com.