|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #44109 sem_remove does not seem to take SYSVSEM_USAGE into account
Submitted: 2008-02-13 13:26 UTC Modified: 2011-02-21 20:50 UTC
Avg. Score:4.8 ± 0.5
Reproduced:14 of 14 (100.0%)
Same Version:2 (14.3%)
Same OS:12 (85.7%)
From: thornza at yahoo dot com Assigned:
Status: Open Package: Semaphore related
PHP Version: 5.2.5 OS: Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: thornza at yahoo dot com
New email:
PHP Version: OS:


 [2008-02-13 13:26 UTC] thornza at yahoo dot com
Two processes - processA and processB - are using a semaphore.

processA sem_get()s the semaphore. (the semaphore is created)
processB sem_get()s the semaphore. (the semaphore is already created, so the semaphore id is just returned)

processA sem_acquire()s the semaphore and begins to work in the critical section.
processB sem_acquire()s the semaphore and BLOCKS.

processA finishes in it's critical section and sem_release()s.
processA sem_remove()s the semaphore ***THE SEMAPHORE HAS NOW BEEN REMOVED - 
I think that this part is incorrect****

processB now is NOT able to continue as the semaphore has been removed.

sem_remove() should take the SYSVSEM_USAGE (see sysvsem.c) count into consideration when it is called. Only if this count is == 1 should the semaphore be removed. This will allow the last process that is using the semaphore to remove it from the system.

Reproduce code:
//Note - run this script from two different clients at the same time.
//add your own critical section code and output logging.
$semKey = 1234;
$semHandle = sem_get($semKey, 1, 0666, FALSE);

//critical section
//do something useful here



Expected result:
processA and processB both able to work in their critical sections without error.

Actual result:
Log messages such as the following are generated:

[13-Feb-2008 14:36:30] PHP Warning:  sem_acquire() [<a href='function.sem-acquire'>function.sem-acquire</a>]: failed to acquire key 0x2b72: Invalid argument in /opt/MarkDW/Exec/Form.php on line 1282


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2011-02-21 20:50 UTC]
-Package: Feature/Change Request +Package: Semaphore related
 [2012-08-23 06:56 UTC] norman dot geist at uni-greifswald dot de
I just got the same annoying problem as the poster.
I tried to use the semaphores with shared memory to create an openmp like parallelism to php scripts and apps.
The problem now is, that if I parallelize a for loop with dynamic scheduling (next free cpu takes next iteration to do) will cause sem_get to run out of semaphore identifiers for the same semaphore. This maximum number of about 32000 seem not to be adjustable. But I can also not use sem_remove to really free the sem ids because the other processes can't access the semaphore no more.

Like this, the semaphores seems just unusable (against their original intention).
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Sun Sep 19 00:03:39 2021 UTC