All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Lange Norbert <norbert.lange@andritz.com>,
	"Xenomai (xenomai@xenomai.org)" <xenomai@xenomai.org>
Subject: Re: Posix skin and Mutex initialisation/destruction inconsistencies
Date: Wed, 6 Mar 2019 18:35:00 +0100	[thread overview]
Message-ID: <4a289496-aad1-5a44-d4bb-288ccc12d68a@siemens.com> (raw)
In-Reply-To: <0e040cd1aa3b4df6ba3c61eb6c1a4adf@andritz.com>

On 06.03.19 10:39, Lange Norbert via Xenomai wrote:
> Hello,
> 
> 1)
> There is an inconsistency with the documentation [1], which claims that mutex and condition variables
> need to be explicitly initialized with the *_init functions.
> The implementation however checks the state via a flag and calls *_init if necessary, and the program below works correctly.

Lazy init is not a recommended pattern as it implies high costs and potentially 
unexpected (and often unhandled) errors for typically critical lock/unlock 
operations. I would guess that this is why it was not explicitly mentioned.

> 
> 2)
> There is some further issue, if you depend on the "lazy initialization", demonstrated by running the
> program below with an argument. This case can happen for example if some subsystem was removed
> before being used (never needed the lock).
> In other words, the "lazy initialization" scheme is working with lock/unlock but not with destroy.
> 
> 
> #include <assert.h>
> #include <pthread.h>
> 
> int main(int argc, char const *argv[]) {
>          pthread_mutex_t mymutex = PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP;
> 
>    if (argc == 1) {
>      assert(0 == pthread_mutex_lock(&mymutex));
>      assert(0 == pthread_mutex_unlock(&mymutex));
>    }
>    assert(0 == pthread_mutex_destroy(&mymutex));

That should probably be fixed. Patch welcome.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


      reply	other threads:[~2019-03-06 17:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-06  9:39 Posix skin and Mutex initialisation/destruction inconsistencies Lange Norbert
2019-03-06 17:35 ` Jan Kiszka [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4a289496-aad1-5a44-d4bb-288ccc12d68a@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=norbert.lange@andritz.com \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.