php.net |  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
Votes:17
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
Have you experienced this issue?
Rate the importance of this bug to you:

 [2008-02-13 13:26 UTC] thornza at yahoo dot com
Description:
------------
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:
---------------
<?php
//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);

sem_acquire($semHandle);
//critical section
//do something useful here
sem_release($semHandle);


sem_remove($semHandle);

?>



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

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-02-21 20:50 UTC] jani@php.net
-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-2019 The PHP Group
All rights reserved.
Last updated: Sat Mar 23 01:01:26 2019 UTC