Re: [Valgrind-users] helgrind, PTHREAD_RWLOCK_INITIALIZER and pthread_rwlock_destroy

[Ivo R. <iv...@iv...>]

2016-10-06 22:27 GMT+02:00 Patrick J. LoPresti <lop...@gm...>:

> On Thu, Oct 6, 2016 at 8:53 AM, Alex Bligh <al...@al...> wrote:
> >
> >
> > > On 6 Oct 2016, at 16:06, Mateusz Jemielity <
> m.j...@is...> 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