2016-10-06 22:27 GMT+02:00 Patrick J. LoPresti <lopre...@gmail.com>:
> On Thu, Oct 6, 2016 at 8:53 AM, Alex Bligh <a...@alex.org.uk> wrote:
> >
> >
> > > On 6 Oct 2016, at 16:06, Mateusz Jemielity <
> m.jemiel...@is-wireless.com> wrote:
> > >
> > > The effects are equivalent to pthread_rwlock_init, thus in my opinion
> they
> > > require pthread_rwlock_destroy.
> >
> > However, I'm not sure why you'd need to call pthread_*_destroy on a
> statically
> > initialised object, given that presumably you destroy it when the program
> > is about to exit and the resources would be given back to the OS anyway.
>
> In this example it is in main(), but there is no reason the same sequence
> could not appear in the middle of a long-running program, in which case
> failing to call pthread_rwlock_destroy() could potentially leak resources.
>
> I agree with Mateusz. POSIX clearly requires a call to
> pthread_rwlock_destroy() on RW locks initialized via PTHREAD_RW_INITIALIZER
> to ensure proper freeing of resources.
>
Indeed, POSIX [1] explicitly says that PTHREAD_RWLOCK_INITIALIZER shall be
equivalent to dynamic initialization by a call to pthread_rwlock_init().
However our tools (DRD, Helgrind) cannot detect such implicitly initialized
primitive easily. Simply because there is no pthread_rwlock_init() called
for them.
For example on Solaris, PTHREAD_RWLOCK_INITIALIZER is a macro which expands
to pthread_rwlock_t with all fields set as if pthread_rwlock_init() was
called instead.
I don't see an efficient way how to fix such false positives.
I.
[1]
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_destroy.html
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
