QNX Operating System/Discussion/OSTech/sem_open() and path issues/List of Posts
 
Forum Topic - sem_open() and path issues:
   
Update
Enrico Simetti
10/03/2009 1:47 PM
post39329
sem_open() and path issues   
Hello all,

I've got a small problem with sem_open(). From the reference (at: http://www.qnx.com/developers/docs/6.4.1/neutrino/
lib_ref/s/sem_open.html ) the following code:

int main(int argc, char** argv)
{
	sem_t* sem_ = sem_open("/var/wf/mysem", O_CREAT | O_EXCL, 0777, 0);
}

should create a semaphore at /var/wf/mysem.

Instead of getting that, i get a semaphore created in /dev/sem called var/wf/mysem
Note that with mq_open() and shm_open() I get the expected behaviour. Just not with sem_open().

Any ideas?
It's a bit annoying because I want all my process to create their resources in a specific folder, so that if anything 
goes wrong (which means my own resource manager dies), i can just delete all of them with rm and implement a simple 
cleanup procedure.
Enrico Simetti
10/04/2009 6:52 AM
post39330
Re: sem_open() and path issues   
Also, is there any way to create a binary semaphore, i.e. not a counting one but limited to 1? Do I have to use a mutex 
to do that?
John Garvey(deleted)
10/06/2009 1:02 PM
post39440
Re: sem_open() and path issues   
> should create a semaphore at /var/wf/mysem.

The docs didn't track the 6.3 change of moving named semaphores directly into the kernel, namely that they now operate 
in a flat namespace under /dev/sem.

This was done to simplify and conserve kernel resources (previously each object was an attached name/mountpt).

This is completely allowed by POSIX (names do not have to appear in the pathspace and the definition of any non-leading 
'/' is implementation-defined).

> Note that with mq_open() and shm_open() I get the expected behaviour. Just not
>  with sem_open().

Actually, mq+libmq operate a similar flat namespace under /dev/mq for the same reasons (mqueue+libc left as-is).
> It's a bit annoying because I want all my process to create their resources in
>  a specific folder, so that if anything goes wrong (which means my own 
> resource manager dies), i can just delete all of them with rm and implement a 
> simple cleanup procedure.

You can still incorporate a unique component into each semaphore name, and then do a wildcard deletion (ie "rm -rf /var/
sem/MYID1/" could be "rm -f /dev/sem/*MYID1*").
Steve Reid(deleted)
10/06/2009 2:19 PM
post39444
RE: sem_open() and path issues   
I created a PR to get the docs updated.


Steve Reid (stever@qnx.com)
Technical Editor
QNX Software Systems 
 

> -----Original Message-----
> From: John Garvey [mailto:community-noreply@qnx.com] 
> Sent: Tuesday, October 06, 2009 1:02 PM
> To: ostech-core_os
> Subject: Re: sem_open() and path issues
> 
> > should create a semaphore at /var/wf/mysem.
> 
> The docs didn't track the 6.3 change of moving named 
> semaphores directly into the kernel, namely that they now 
> operate in a flat namespace under /dev/sem.
> 
> This was done to simplify and conserve kernel resources 
> (previously each object was an attached name/mountpt).
> 
> This is completely allowed by POSIX (names do not have to 
> appear in the pathspace and the definition of any non-leading 
> '/' is implementation-defined).
> 
> > Note that with mq_open() and shm_open() I get the expected 
> behaviour. Just not
> >  with sem_open().
> 
> Actually, mq+libmq operate a similar flat namespace under 
> /dev/mq for the same reasons (mqueue+libc left as-is).
> > It's a bit annoying because I want all my process to create 
> their resources in
> >  a specific folder, so that if anything goes wrong (which 
> means my own 
> > resource manager dies), i can just delete all of them with 
> rm and implement a 
> > simple cleanup procedure.
> 
> You can still incorporate a unique component into each 
> semaphore name, and then do a wildcard deletion (ie "rm -rf 
> /var/sem/MYID1/" could be "rm -f /dev/sem/*MYID1*").  
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post39440
> 
>
Enrico Simetti
10/06/2009 2:51 PM
post39450
Re: sem_open() and path issues   
> You can still incorporate a unique component into each semaphore name, and 
> then do a wildcard deletion (ie "rm -rf /var/sem/MYID1/" could be "rm -f /dev/
> sem/*MYID1*").  

I guess that could be a good solution to that problem. Thanks for pointing that out :)

I still have one open issue with semaphores, and that is how to have counting semaphores counting up to a specified 
amount (e.g. binary semaphores) and not up to the SEM_VALUE_MAX constant. I'm either blind or there's nothing in the 
docs that suggests it being possible (unless by first checking the value of the semaphore and then deciding or not to do
 the sem_post() depending on its value).

Did I miss something?
Brian Stecher(deleted)
10/07/2009 9:30 AM
post39509
Re: sem_open() and path issues   
On Tue, Oct 06, 2009 at 02:51:20PM -0400, Enrico Simetti wrote:
> I still have one open issue with semaphores, and that is how to have counting semaphores counting up to a specified 
amount (e.g. binary semaphores) and not up to the SEM_VALUE_MAX constant. I'm either blind or there's nothing in the 
docs that suggests it being possible (unless by first checking the value of the semaphore and then deciding or not to do
 the sem_post() depending on its value).

POSIX decrees that its semphares are always counting. To get binary
behaviour, you need to use a mutex.

-- 
Brian Stecher (bstecher@qnx.com)        QNX Software Systems
phone: +1 (613) 591-0931 (voice)        175 Terence Matthews Cr.
       +1 (613) 591-3579 (fax)          Kanata, Ontario, Canada K2M 1W8

Return