php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #57177 Add named locks
Submitted: 2006-08-10 13:29 UTC Modified: 2007-02-24 06:43 UTC
From: david at acz dot org Assigned:
Status: Closed Package: APC (PECL)
PHP Version: Irrelevant OS: Any
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: david at acz dot org
New email:
PHP Version: OS:

 

 [2006-08-10 13:29 UTC] david at acz dot org
Description:
------------
It would be useful to have generic named locks, similar to MySQL's GET_LOCK / RELEASE_LOCK.  The lock function would have an optional timeout.

Deadlocks are possible.  One option is automatic deadlock detection.  The other option is to only allow one lock per PHP instance (a second successful lock call unlocks a previously held lock), which is the option chosen by MySQL.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-08-14 11:13 UTC] gopalv82 at yahoo dot com
Not really APCs problem and the feature doesn't quite make sense either. Especially since php code with blocking locks are a VERY VERY bad idea.
 [2006-08-14 12:45 UTC] david at acz dot org
It makes sense when using the APC cache:

apc_lock("hits");
$hits = apc_fetch("hits");
$hits++;
apc_store("hits", $hits);
apc_unlock("hits");

I can submit a patch for this.
 [2006-08-14 12:50 UTC] rasmus@php.net
You are comparing this to MySQL, but in the case of MySQL there is a single mysql server daemon that can manage the locks.  PHP is typically run in a multi-process architecture which makes this way more brittle.  I think an atomic increment function would make more sense.  It could be flexible enough to do something along the lines of:

  apc_inc('hits',1);
  apc_inc('items,-1);
  apc_inc('score',1000);
 [2006-08-14 12:50 UTC] rasmus@php.net
You are comparing this to MySQL, but in the case of MySQL there is a single mysql server daemon that can manage the locks.  PHP is typically run in a multi-process architecture which makes this way more brittle.  I think an atomic increment function would make more sense.  It could be flexible enough to do something along the lines of:

  apc_inc('hits',1);
  apc_inc('items,-1);
  apc_inc('score',1000);
 [2006-08-14 13:04 UTC] david at acz dot org
APC must already support locking for it's own internal data structures, so I figure that could be re-used.  However, atomic inc/dec like memcached, while not as flexible, would eliminate much (though certainly not all) of the need for locking.  It would be nice to have both, but I'll settle for the latter.
 [2006-08-17 08:37 UTC] mauroi at digbang dot com
local locks are, even if you have more than one webserver, a way to avoid a race condition when writing a resource to disk, or something like that....
i think that http://www.php.net/manual/en/ref.sem.php or simply flock (over a tmpfs) could be used.
however apc_inc would be a nice shortcut for a one server application.
 [2007-02-24 06:43 UTC] rasmus@php.net
I think the addition of apc_add() takes care of this as far as we can really take it.  apc_add() is identical to apc_store() except it only stores the entry if it isn't already there and returns false otherwise.  So something along the lines of:

if(apc_add("MyLock",1)) { my_code(); apc_delete("MyLock"); }

should do the trick here.  You could even put a timeout on the lock.  apc_add() obviously doesn't block, so how you choose to retest the lock is up to you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 15:01:28 2024 UTC