Project

General

Profile

[logo] 
 
Home
About/Contact
Major Tools
  Dinotrace
  Verilator
  Verilog-mode
  Verilog-Perl
Other Tools
  IPC::Locker
  Parallel::Forker
  Voneline
General Info
  Papers

Issue #114

Locking issues

Added by Wilson Snyder almost 11 years ago. Updated almost 11 years ago.

Status:
NoFixNeeded
Priority:
Normal
Assignee:
% Done:

0%


Description

This bug was cloned from Perl-RT, rt49833.

Email addresses have have been truncated.

Id:   49833
Status:        open
Queue:         IPC-Locker
Fixed in:     1.484
Requestors:    skrisna <skrisna@>
X Attachments
locker_stress

Created:    Sat Sep 19 05:27:21 2009
Last Contact:     Sat Sep 19 07:47:33 2009
Closed:     Not set
Updated:     Sat Sep 19 07:47:33 2009 by WSNYDER
Sat Sep 19 05:27:26 2009 skrisna - Ticket created
Subject:  Locking issues
We, at BBN Technologies, have been toying with IPC::Locker to solve
pretty massive network concurrency issues. Upon using it for a while, we
found that the server/client works fine for the most part. But at times,
some clients get stalled forever. We have not been able to debug this
problem but here is what we found-

If there are a lot (400+ clients) trying to talk to the server at the
same time asking for different locks, and if three or more clients ask
for the same lock at the same time and are setup to be blocking, then
this is what happens:

Lets say A,B,C are three clients requesting the same lock at the same
time. The server serves A and puts B and C into waiting. Once A is
finished with the lock, it serves B with the same lock. In the meantime,
client D also requests the same lock from the server. After B, the
server serves D with the lock but forgets to ever serve C. So C goings
into infinite wait and stalls.

I haven't had a chance to look at the server code but will try doing
some debugging at our end to resolve this issue.

Thanks,
Krishna
Sat Sep 19 07:47:31 2009 WSNYDER - Correspondence added
Sorry you are having problems. I've been using it on 500ish node clumps
(with a few larger test runs) and haven't seen this issue, but I'm not
sure I'd notice unfairness; I would notice giving locks to multiple
people though as we unfortunately had that problem at one point in
development.

I've attached a program to stress out the locker from one multi-cpu
machine. I then run this on many machines in parallel (manually).
Unfortunately it may not check for your problem, nor can it check other
than between threads that there's multiple owners of the lock (as this
would require a different lock mechanism).

Now that I think of it, maybe I should have the stress talk to two
daemons, then it could use the second to check that no one else has the
lock.

Anyhow, let me know if you find the issue.
Subject:    locker_stress
Sat Sep 19 07:47:33 2009 RT_System - Status changed from 'new' to 'open'
Subject: [rt.cpan.org #49833] Locking issues
RT-Ticket: rt.cpan.org #49833
Managed-by: RT 3.6.HEAD (http://www.bestpractical.com/rt/)
Date: Mon, 21 Sep 2009 14:43:53 -0400

       Queue: IPC-Locker
 Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=49833 >

I found the problem - it had nothing to do with IPC::Locker. My locking
system needed me to generate unique user ids everytime I ran it. and I
was using

srand(time ^ $$ ^ unpack "%L*", `ps axww | gzip`);

to initialize the random number generator. By some strange chance, this
was producing the same random number when I used

rand(100000000);

for two distinct processes. I am closing this ticket.

Thanks,
Krishna

Also available in: Atom