Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/rwlock in shared mem/List of Posts
Forum Topic - rwlock in shared mem: (16 Items)
   
Update
Mario Charest
05/19/2011 10:24 AM
post85941
rwlock in shared mem   
We setup a shared mem with about 10 rwlock in it.  Everythink work as expected, unless the program terminates without 
deleting this shared mem.

On restart the program reuses the same sharemem and is unable to initialised the rwlock, errno says EINVAL on some and 
ESRCH or others.  I print every value of the attribute and rwlock_t structure and they are the same in all scenarios.

I don't understand why it works on a freshly created sharedmem and does not if it is reopen.  In both cases the 
sharedmem is zeroed out before initialising the rwlocks.
Dennis Kellly
05/19/2011 10:46 AM
post85944
RE: rwlock in shared mem   
Had a customer with a similar issue using a semaphore.  Try adding a
call to pthread_rwlock_destroy() on failure and then retry the init.
Calling "sem_destroy()" this way worked for him.

Dennis

-----Original Message-----
From: Mario Charest [mailto:community-noreply@qnx.com] 
Sent: Thursday, May 19, 2011 10:24 AM
To: ostech-core_os
Subject: rwlock in shared mem


We setup a shared mem with about 10 rwlock in it.  Everythink work as
expected, unless the program terminates without deleting this shared
mem.

On restart the program reuses the same sharemem and is unable to
initialised the rwlock, errno says EINVAL on some and ESRCH or others.
I print every value of the attribute and rwlock_t structure and they are
the same in all scenarios.

I don't understand why it works on a freshly created sharedmem and does
not if it is reopen.  In both cases the sharedmem is zeroed out before
initialising the rwlocks.





_______________________________________________

OSTech
http://community.qnx.com/sf/go/post85941
Mario Charest
05/19/2011 1:34 PM
post85951
RE: rwlock in shared mem   

> -----Message d'origine-----
> De : Dennis Kellly [mailto:community-noreply@qnx.com]
> Envoyé : 19 mai 2011 10:46
> À : ostech-core_os
> Objet : RE: rwlock in shared mem
> 
> Had a customer with a similar issue using a semaphore.  Try adding a call to
> pthread_rwlock_destroy() on failure and then retry the init.

Wow it works, I`m surprise because the memory that hold the rwlock is zeroed before hand!!  That would seem to imply 
that the kernel keep track of the existence of the rwlock through its address ?!?

Thanks Dennis!

> Calling "sem_destroy()" this way worked for him.
> 
> Dennis
> 
> -----Original Message-----
> From: Mario Charest [mailto:community-noreply@qnx.com]
> Sent: Thursday, May 19, 2011 10:24 AM
> To: ostech-core_os
> Subject: rwlock in shared mem
> 
> 
> We setup a shared mem with about 10 rwlock in it.  Everythink work as
> expected, unless the program terminates without deleting this shared
> mem.
> 
> On restart the program reuses the same sharemem and is unable to
> initialised the rwlock, errno says EINVAL on some and ESRCH or others.
> I print every value of the attribute and rwlock_t structure and they are
> the same in all scenarios.
> 
> I don't understand why it works on a freshly created sharedmem and does
> not if it is reopen.  In both cases the sharedmem is zeroed out before
> initialising the rwlocks.
> 
> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post85941
> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post85944
>
Dennis Kellly
05/19/2011 1:39 PM
post85952
Re: RE: rwlock in shared mem   
>>> I`m surprise because the memory that hold the rwlock is zeroed before hand!! 

I was surprised as well when it worked for my customer (even though I suggested it).

I hope someone can give us an explanation of WHY it works.

Dennis
Jerry Sui
05/19/2011 2:17 PM
post85956
RE: RE: rwlock in shared mem   
The kernel sync objects will not be destroyed until you call
pthread_rwlock_destroy() or until you unmap() the memory. Zero the
memory won't help in this case because the kernel sync objects are in a
hash table indexed by some bits of the virtual memory address. The
individual sync object is then uniquely identified by the physical
address and virtual address. In your case, because the shared memory is
not unmapped, both the virtual address and physical address remains
same, So you end up using the same previous allocated object that is not
destroyed. 

Jerry Sui | Software Developer | jsui@qnx.com
O:613-591-0836 x 2904 C:613-240-9239 | www.qnx.com | QNX Software
Systems
Cisco Support Team email: cisco_support@qnx.com

-----Original Message-----
From: Dennis Kellly [mailto:community-noreply@qnx.com] 
Sent: May-19-11 1:39 PM
To: ostech-core_os
Subject: Re: RE: rwlock in shared mem

>>> I`m surprise because the memory that hold the rwlock is zeroed
before hand!! 

I was surprised as well when it worked for my customer (even though I
suggested it).

I hope someone can give us an explanation of WHY it works.

Dennis



_______________________________________________

OSTech
http://community.qnx.com/sf/go/post85952
Dennis Kellly
05/19/2011 2:30 PM
post85959
Re: RE: RE: rwlock in shared mem   
Thanks Jerry for the details.  Alll well and good except in the customer's case both of the processes which were 
attached to the memory had exitted.

He indicated that the issue only repeated on a target running a "tiny" image (not very much activity) - but not on a 
full desktop setup.  This  led me to suspect  he may have gotten the same physical memory block returned on a later 
mmap() - and that was causing the issue.

Dennis
Jerry Sui
05/19/2011 2:41 PM
post85962
RE: RE: RE: rwlock in shared mem   
Please answer the following questions:

Did he unmap() the shared memory when he exited the processes? 
What processor is he using? X86? 
How big was the shared memory? Was it over 2M/4M?

Jerry Sui | Software Developer | jsui@qnx.com
O:613-591-0836 x 2904 C:613-240-9239 | www.qnx.com | QNX Software
Systems
Cisco Support Team email: cisco_support@qnx.com


-----Original Message-----
From: Dennis Kellly [mailto:community-noreply@qnx.com] 
Sent: May-19-11 2:30 PM
To: ostech-core_os
Subject: Re: RE: RE: rwlock in shared mem

Thanks Jerry for the details.  Alll well and good except in the
customer's case both of the processes which were attached to the memory
had exitted.

He indicated that the issue only repeated on a target running a "tiny"
image (not very much activity) - but not on a full desktop setup.  This
led me to suspect  he may have gotten the same physical memory block
returned on a later mmap() - and that was causing the issue.

Dennis





_______________________________________________

OSTech
http://community.qnx.com/sf/go/post85959
Dennis Kellly
05/19/2011 2:54 PM
post85964
Re: RE: RE: RE: rwlock in shared mem   
>>>What processor is he using? X86? 
x86

>>>How big was the shared memory? Was it over 2M/4M?
A few hundred bytes

>>>Did he unmap() the shared memory when he exited the processes? 
He use terminated the apps without unmapping.  

I assumed that on termination the reference count would go to zero and the kernel would unmap.
Jerry Sui
05/19/2011 3:57 PM
post85971
RE: RE: RE: RE: rwlock in shared mem   
I fixed a issue that the sync objects not being destroyed in big
pages(2M or 4M) in x86 when the pages are unmapped. Not sure if this is
related. Please see PR# 87968 for details.

Jerry Sui | Software Developer | jsui@qnx.com
O:613-591-0836 x 2904 C:613-240-9239 | www.qnx.com | QNX Software
Systems
Cisco Support Team email: cisco_support@qnx.com


-----Original Message-----
From: Dennis Kellly [mailto:community-noreply@qnx.com] 
Sent: May-19-11 2:54 PM
To: ostech-core_os
Subject: Re: RE: RE: RE: rwlock in shared mem

>>>What processor is he using? X86? 
x86

>>>How big was the shared memory? Was it over 2M/4M?
A few hundred bytes

>>>Did he unmap() the shared memory when he exited the processes? 
He use terminated the apps without unmapping.  

I assumed that on termination the reference count would go to zero and
the kernel would unmap.





_______________________________________________

OSTech
http://community.qnx.com/sf/go/post85964
Mario Charest
05/20/2011 11:20 AM
post86013
RE: RE: RE: RE: rwlock in shared mem   

> -----Message d'origine-----
> De : Jerry Sui [mailto:community-noreply@qnx.com]
> Envoyé : 19 mai 2011 15:58
> À : ostech-core_os
> Objet : RE: RE: RE: RE: rwlock in shared mem
> 
> I fixed a issue that the sync objects not being destroyed in big pages(2M or
> 4M) in x86 when the pages are unmapped. Not sure if this is related. Please
> see PR# 87968 for details.

Ah that probably explain some weird behavior we get sometimes that only a reboot can fix. 

Cheers

> 
> Jerry Sui | Software Developer | jsui@qnx.com
> O:613-591-0836 x 2904 C:613-240-9239 | www.qnx.com | QNX Software
> Systems Cisco Support Team email: cisco_support@qnx.com
> 
> 
> -----Original Message-----
> From: Dennis Kellly [mailto:community-noreply@qnx.com]
> Sent: May-19-11 2:54 PM
> To: ostech-core_os
> Subject: Re: RE: RE: RE: rwlock in shared mem
> 
> >>>What processor is he using? X86?
> x86
> 
> >>>How big was the shared memory? Was it over 2M/4M?
> A few hundred bytes
> 
> >>>Did he unmap() the shared memory when he exited the processes?
> He use terminated the apps without unmapping.
> 
> I assumed that on termination the reference count would go to zero and the
> kernel would unmap.
> 
> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post85964
> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post85971
>
David Sarrazin
05/19/2011 2:58 PM
post85965
RE: RE: RE: rwlock in shared mem   
Is it a named shared memory object?  If it was, and the name still
existed, then the shared memory would persist, even after both processes
exited.

> -----Original Message-----
> From: Dennis Kellly [mailto:community-noreply@qnx.com]
> Sent: May-19-11 2:30 PM
> To: ostech-core_os
> Subject: Re: RE: RE: rwlock in shared mem
> 
> Thanks Jerry for the details.  Alll well and good except in the
> customer's case both of the processes which were attached to the
memory
> had exitted.
> 
> He indicated that the issue only repeated on a target running a "tiny"
> image (not very much activity) - but not on a full desktop setup.
This
> led me to suspect  he may have gotten the same physical memory block
> returned on a later mmap() - and that was causing the issue.
> 
> Dennis
> 
> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post85959
Dennis Kellly
05/19/2011 2:59 PM
post85966
Re: RE: RE: RE: rwlock in shared mem   
It was not "named".  He was using fork()-  so no requirement for a name.
Jerry Sui
05/19/2011 4:13 PM
post85973
Re: RE: RE: RE: rwlock in shared mem   
>>>I don't understand why it works on a freshly created sharedmem and does
not if it is reopen.

It looks like he is using a named share memory. Because he said " reopen". It can be well explained by previous posts if
 the memory is reopened instead of recreated.
Mario Charest
05/23/2011 3:00 PM
post86058
RE: RE: rwlock in shared mem   
Reading the doc on rwlock is says the kernel has no knowledge of rwlocks, this is somewhat confusing as one might expect
 a different behaviour that what you described.

> -----Message d'origine-----
> De : Jerry Sui [mailto:community-noreply@qnx.com]
> Envoyé : 19 mai 2011 14:18
> À : ostech-core_os
> Objet : RE: RE: rwlock in shared mem
> 
> The kernel sync objects will not be destroyed until you call
> pthread_rwlock_destroy() or until you unmap() the memory. Zero the
> memory won't help in this case because the kernel sync objects are in a hash
> table indexed by some bits of the virtual memory address. The individual
> sync object is then uniquely identified by the physical address and virtual
> address. In your case, because the shared memory is not unmapped, both
> the virtual address and physical address remains same, So you end up using
> the same previous allocated object that is not destroyed.
> 
> Jerry Sui | Software Developer | jsui@qnx.com
> O:613-591-0836 x 2904 C:613-240-9239 | www.qnx.com | QNX Software
> Systems Cisco Support Team email: cisco_support@qnx.com
> 
> -----Original Message-----
> From: Dennis Kellly [mailto:community-noreply@qnx.com]
> Sent: May-19-11 1:39 PM
> To: ostech-core_os
> Subject: Re: RE: rwlock in shared mem
> 
> >>> I`m surprise because the memory that hold the rwlock is zeroed
> before hand!!
> 
> I was surprised as well when it worked for my customer (even though I
> suggested it).
> 
> I hope someone can give us an explanation of WHY it works.
> 
> Dennis
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post85952
> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post85956
>
David Sarrazin
05/23/2011 3:27 PM
post86059
Re: rwlock in shared mem   
Rwlocks are implemented as a mutex and a few condvars.  Even though the kernel doesn't know that your using it as a 
rwlock, the underlying primitives must still be cleaned up.



On 2011-05-23, at 3:01 PM, "Mario Charest" <community-noreply@qnx.com> wrote:

> 
> Reading the doc on rwlock is says the kernel has no knowledge of rwlocks, this is somewhat confusing as one might 
expect a different behaviour that what you described.
> 
>> -----Message d'origine-----
>> De : Jerry Sui [mailto:community-noreply@qnx.com]
>> Envoyé : 19 mai 2011 14:18
>> À : ostech-core_os
>> Objet : RE: RE: rwlock in shared mem
>> 
>> The kernel sync objects will not be destroyed until you call
>> pthread_rwlock_destroy() or until you unmap() the memory. Zero the
>> memory won't help in this case because the kernel sync objects are in a hash
>> table indexed by some bits of the virtual memory address. The individual
>> sync object is then uniquely identified by the physical address and virtual
>> address. In your case, because the shared memory is not unmapped, both
>> the virtual address and physical address remains same, So you end up using
>> the same previous allocated object that is not destroyed.
>> 
>> Jerry Sui | Software Developer | jsui@qnx.com
>> O:613-591-0836 x 2904 C:613-240-9239 | www.qnx.com | QNX Software
>> Systems Cisco Support Team email: cisco_support@qnx.com
>> 
>> -----Original Message-----
>> From: Dennis Kellly [mailto:community-noreply@qnx.com]
>> Sent: May-19-11 1:39 PM
>> To: ostech-core_os
>> Subject: Re: RE: rwlock in shared mem
>> 
>>>>> I`m surprise because the memory that hold the rwlock is zeroed
>> before hand!!
>> 
>> I was surprised as well when it worked for my customer (even though I
>> suggested it).
>> 
>> I hope someone can give us an explanation of WHY it works.
>> 
>> Dennis
>> 
>> 
>> 
>> _______________________________________________
>> 
>> OSTech
>> http://community.qnx.com/sf/go/post85952
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 
>> OSTech
>> http://community.qnx.com/sf/go/post85956
>> 
> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post86058
Mario Charest
05/23/2011 4:12 PM
post86063
RE: rwlock in shared mem   
Then is it entirely true that rwlock don`t respect priorities?

> -----Message d'origine-----
> De : David Sarrazin [mailto:community-noreply@qnx.com]
> Envoyé : 23 mai 2011 15:28
> À : ostech-core_os
> Objet : Re: rwlock in shared mem
> 
> Rwlocks are implemented as a mutex and a few condvars.  Even though the
> kernel doesn't know that your using it as a rwlock, the underlying primitives
> must still be cleaned up.
> 
> 
> 
> On 2011-05-23, at 3:01 PM, "Mario Charest" <community-noreply@qnx.com>
> wrote:
> 
> >
> > Reading the doc on rwlock is says the kernel has no knowledge of rwlocks,
> this is somewhat confusing as one might expect a different behaviour that
> what you described.
> >
> >> -----Message d'origine-----
> >> De : Jerry Sui [mailto:community-noreply@qnx.com]
> >> Envoyé : 19 mai 2011 14:18
> >> À : ostech-core_os
> >> Objet : RE: RE: rwlock in shared mem
> >>
> >> The kernel sync objects will not be destroyed until you call
> >> pthread_rwlock_destroy() or until you unmap() the memory. Zero the
> >> memory won't help in this case because the kernel sync objects are in
> >> a hash table indexed by some bits of the virtual memory address. The
> >> individual sync object is then uniquely identified by the physical
> >> address and virtual address. In your case, because the shared memory
> >> is not unmapped, both the virtual address and physical address
> >> remains same, So you end up using the same previous allocated object
> that is not destroyed.
> >>
> >> Jerry Sui | Software Developer | jsui@qnx.com
> >> O:613-591-0836 x 2904 C:613-240-9239 | www.qnx.com | QNX Software
> >> Systems Cisco Support Team email: cisco_support@qnx.com
> >>
> >> -----Original Message-----
> >> From: Dennis Kellly [mailto:community-noreply@qnx.com]
> >> Sent: May-19-11 1:39 PM
> >> To: ostech-core_os
> >> Subject: Re: RE: rwlock in shared mem
> >>
> >>>>> I`m surprise because the memory that hold the rwlock is zeroed
> >> before hand!!
> >>
> >> I was surprised as well when it worked for my customer (even though I
> >> suggested it).
> >>
> >> I hope someone can give us an explanation of WHY it works.
> >>
> >> Dennis
> >>
> >>
> >>
> >> _______________________________________________
> >>
> >> OSTech
> >> http://community.qnx.com/sf/go/post85952
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >>
> >> OSTech
> >> http://community.qnx.com/sf/go/post85956
> >>
> >
> >
> >
> >
> > _______________________________________________
> >
> > OSTech
> > http://community.qnx.com/sf/go/post86058
> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post86059

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems