From: Arjan van de Ven <arjan@linux.intel.com>
To: Oleg Drokin <green@linuxhacker.ru>,
Jeff Layton <jlayton@poochiereds.net>
Cc: Peter Zijlstra <peterz@infradead.org>,
Mailing List <linux-kernel@vger.kernel.org>,
mingo@redhat.com, "J . Bruce Fields" <bfields@fieldses.org>
Subject: Re: initialize a mutex into locked state?
Date: Fri, 17 Jun 2016 07:59:25 -0700 [thread overview]
Message-ID: <d4e6ca53-79bc-b0ac-1a60-9460fe1bf856@linux.intel.com> (raw)
In-Reply-To: <E4F8DDF2-ACDE-4D7A-8133-E55CFA464751@linuxhacker.ru>
On 6/17/2016 7:54 AM, Oleg Drokin wrote:
>
> Yes, we can add all sorts of checks that have various impacts on code readability,
> we can also move code around that also have code readability and CPU impact.
>
> But in my discussion with Arjan he said this is a new use case that was not met before
> and suggested to mail it to the list.
I'm all in favor of having "end code" be as clear as possible wrt intent.
(and I will admit this is an curious use case, but not an insane silly one)
one other option is to make a wrapper
mutex_init_locked( )
{
mutex_init()
mutex_trylock()
}
that way the wrapper can be an inline in a header, but doesn't need to touch a wide
berth of stuff... while keeping the end code clear wrt intent
next prev parent reply other threads:[~2016-06-17 14:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-15 18:23 initialize a mutex into locked state? Oleg Drokin
2016-06-17 8:25 ` Peter Zijlstra
2016-06-17 14:14 ` Oleg Drokin
2016-06-17 14:19 ` Peter Zijlstra
2016-06-17 14:24 ` Oleg Drokin
2016-06-17 14:32 ` Peter Zijlstra
2016-06-17 14:40 ` Oleg Drokin
2016-06-17 14:42 ` Jeff Layton
2016-06-17 14:54 ` Oleg Drokin
2016-06-17 14:59 ` Arjan van de Ven [this message]
2016-06-17 14:59 ` Peter Zijlstra
[not found] ` <CAC0gvwFhyahkP9M7Ktfd0GOv8CJbkeVegSfc57XpEUk8qAGA1w@mail.gmail.com>
2016-06-17 14:46 ` Oleg Drokin
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=d4e6ca53-79bc-b0ac-1a60-9460fe1bf856@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=bfields@fieldses.org \
--cc=green@linuxhacker.ru \
--cc=jlayton@poochiereds.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.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.