johnnywang has asked for the wisdom of the Perl Monks concerning the following question:

Hi, I'm trying to use IPC:Shareable on linux. I'm testing with the following snippet:
use strict; use IPC::Shareable; my @test; my $shared = tie @test, 'IPC::Shareable', 'Test', {create=>1, mode=>06 +66}; $shared->shlock(); push @test, scalar(localtime); # just add something print join("\n", @test),"\n"; $shared->shunlock();
This code does the correct thing: each time I ran it, it adds a timestamp to the list. However, if I commented out the last line (simulating a failure before unlocking), the array does not grow, instead the last element was updated. From reading the documentation, it seems that since it is not unlocked, the other process can still obtain the tie, but can't change it. My question is why the lock is still there when the process ends? and if now I put back the last line, the program behaves back to normal again. What happened to the locks?

When one process is having the lock, is it possible for the other process to wait for the lock (like a typical synchronization), rather than getting a copy of the tied data? Thanks.

Replies are listed 'Best First'.
Re: Shared memory with IPC::Shareable
by perrin (Chancellor) on Nov 02, 2004 at 18:04 UTC
    Based on the lack of comments, I would say not many people use IPC::Shareable for anything tricky. Doesn't it handle the locks for you automatically if you just access the variables normally?

    I suspect the lock stays around because that's just how SysV IPC works. You might be happier using a database for this, or BerkelyDB. Those tend to be faster than IPC::Shareable as well.

Re: Shared memory with IPC::Shareable
by kscaldef (Pilgrim) on Apr 12, 2005 at 23:52 UTC
    What version are you using? At least in 0.60, any locks are released in an END block if you forget to (assuming your program exits normally). However, if you have an older version, this might be explained by a performance optimization that IPC::Shareable uses. When you have a write lock on a segment, the changes you make are not immediately written to the shared memory segment. Rather, they are deferred until the unlock happens, to avoid freezing and thawing repeatedly. So, you can see how it might appear that you are updating the shared object, but if you don't unlock other processes will never see it.