os::current_thread_id on Linux
David Holmes
david.holmes at oracle.com
Fri Jul 24 00:28:49 UTC 2015
On 24/07/2015 4:03 AM, Jeremy Manson wrote:
> Quick rundown:
Thanks - sorry I couldn't get to this last night.
> On Solaris, osthread and current_thread_id are the same (thr_self()).
So both user-thread
> On Windows, they are the same (GetCurrentThreadId()).
Windows is single-level.
> On OS X, they are the same (pthread_mach_thread_np(::pthread_self()))
Both "kernel" thread
> On AIX, current_thread_id is pthread_self, and osthread is thread_self()
> On non-OS X BSD, current_thread_id is pthread_self, and osthread is the
> syscall.
One user and one kernel.
> I don't see any code that depends on the particular value of
> current_thread_id (for example, assuming that it is the same as
> thread_self in a meaningful way on AIX, or that it is pthread_self on
> AIX). My guess is that the AIX and non-OS X code are just following the
> Linux convention.
Yes - port by copy. :(
> I'm happy to make current_thread_id consistent with
> osthread on all of the platforms, or just on Linux (with the
> understanding that I can't really test AIX and OS X easily).
Just make the change on Linux, there's really no consistency here to aim
for. :(
Thanks,
David
> Jeremy
>
> On Thu, Jul 23, 2015 at 12:16 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
> On 23/07/2015 4:11 PM, Jeremy Manson wrote:
>
> Okay. TBH, thinking about it more, it's a little weird for
> something
> named os::current_thread_id() to be different from
> Thread::current()->osThread->thread_id(), or for either of them
> to be
> different from "what the OS thinks the thread id is", so it
> seems like
> the Right Thing to Do (in the absence of any platform-specific
> issues).
>
>
> When there are two different levels of thread ID it isn't that
> simple - especially as, like you say, one can be used to look in
> /proc while the other can't. So perhaps better naming is in order.
>
> Cheers,
> David
>
> Jeremy
>
> On Wed, Jul 22, 2015 at 10:57 PM, David Holmes
> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
> <mailto:david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>>> wrote:
>
> On 23/07/2015 3:15 PM, Jeremy Manson wrote:
>
> Hey David,
>
> Thanks for the offer of sponsorship. My goal here is
> really to
> make the
> log output on Linux usable. I want to be able to map
> the log output
> back to an actual thread. I don't think it really
> matters to
> users if
> the API consistently means "kernel thread ID" or
> "threading API
> thread
> ID", as long as they can figure out what the output means.
>
>
> I think consistency is important else developers don't know
> what
> they should be using where - which is the current situation.
>
> Since what I am doing (in effect) to accomplish my goal
> is to ensure
> that the API returns the same value as
> osthread()->thread_id()
> does for
> the current thread, I could just... do precisely that.
> os::current_thread_id could just return
> osthread()->thread_id()
> for the
> current thread. I don't have easy access to anything
> for testing
> other
> than Linux, though, so whether it worked (or even
> compiled) on
> the other
> platforms would be a bit of a guess (per the last time
> we did
> this dance).
>
>
> Defining os::current_thread_id() to be
> Thread::current()->osThread()->thread_id() assumes you can make
> those calls in the context in which os::current_thread_id()
> is used
> - if we crash during thread startup then some of those may
> be null
> and the id not even set. The current implementation is
> independent
> of the state of thread within the VM.
>
> So its okay to return the same thing as
> Thread::current()->osThread()->thread_id() but it needs to
> be done
> directly.
>
> Again any platform for which this would cause a change in
> behaviour
> needs to be examined. It may be other platforms have the same
> problem you are trying to fix for linux.
>
> If I get time later I'll try to check what each platform does.
>
> Thanks,
> David
>
> Seem reasonable?
>
> Jeremy
>
> On Wed, Jul 22, 2015 at 7:08 PM, David Holmes
> <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>>
> <mailto:david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>
>
> <mailto:david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>>>> wrote:
>
> On 23/07/2015 8:01 AM, Jeremy Manson wrote:
>
> Based on the feedback, this seems to be a good
> idea,
> approximately.
> Coleen would have sponsored, but she's going
> on vacation.
> Anyone else
> feel like sponsoring?
>
>
> Hold up a minute! :) There are different notions
> of "native
> thread
> id" that exist. First we have the "user level
> thread id" -
> this is
> what is reported by pthread_self in POSIX and
> thr_self in
> UI. Then
> we also have the OS specific "thread" id, also
> referred to
> as a LWP
> or "kernel scheduling entity" or "kernel thread" -
> the id
> for this
> is what gettid() maps back to on Linux. This
> distinction
> may not
> exist on all platforms.
>
> Unfortunately os::current_thread_id does not
> define which
> of these
> it represents:
>
> // thread id on Linux/64bit is 64bit, on Windows and
> Solaris, it's
> 32bit
> static intx current_thread_id();
>
> and so on some platforms it returns the "user
> thread id" (eg
> pthread_self()), and on some it returns the same
> as gettid
> (ie OSX -
> but I don't know if the mach thread id is truly a
> "LWP" id ?).
>
> Also note that on some platforms the osThread
> stores the id
> of the
> "user-level thread" and on some the "kernel
> thread". Hence
> another
> source of confusion. :(
>
> So if you want to enforce that os::current_thread_id()
> represents
> the "kernel thread" then that should be applied
> consistently across
> all platforms**, and for platforms for which there
> is a
> change to
> make you have to ensure the usage of
> os::current_thread_id() is not
> semantically altered by the change.
>
> ** Of course a platform may only have a single
> notion of
> "thread"
>
> I'm happy to sponsor such a proposal. And don't
> worry about
> maintaining compatibility with archaic Linux
> versions for
> JDK9 (less
> cleanup to do later).
>
> Thanks,
> David
>
> Jeremy
>
> On Wed, Jul 22, 2015 at 11:22 AM, Jeremy Manson
> <jeremymanson at google.com
> <mailto:jeremymanson at google.com>
> <mailto:jeremymanson at google.com
> <mailto:jeremymanson at google.com>>
> <mailto:jeremymanson at google.com <mailto:jeremymanson at google.com>
> <mailto:jeremymanson at google.com
> <mailto:jeremymanson at google.com>>>
> <mailto:jeremymanson at google.com
> <mailto:jeremymanson at google.com>
> <mailto:jeremymanson at google.com
> <mailto:jeremymanson at google.com>>
>
> <mailto:jeremymanson at google.com
> <mailto:jeremymanson at google.com>
> <mailto:jeremymanson at google.com
> <mailto:jeremymanson at google.com>>>>> wrote:
>
> Hey folks,
>
> os::current_thread_id on Linux now maps to
> pthread_self. The
> problem with pthread_self is that it only
> makes
> sense in
> the context
> of the running process. When it is
> written out to
> the log
> (as it is
> in several places), there really isn't a way
> (AFAICT) for
> the user
> to map it back to anything useful.
>
> As it happens, that value is mostly used
> to write
> to the
> log. The
> places where it doesn't do so don't seem
> to need
> to use
> pthread_self
> for any particular reason.
>
> Meanwhile, the SIGQUIT stack dump
> uses java_thread->osthread()->thread_id()
> as the
> nid. On
> Linux,
> that maps back to os::Linux::gettid(),
> whish is
> also what gets
> exposed in /proc. That makes it much
> easier to
> see what
> threads
> might be doing the log write.
>
> Would it be okay to change
> os::current_thread_id
> to point
> to os::Linux::gettid()? That way, it can be
> mapped back to the
> output of a SIGQUIT dump.
>
> The downside of gettid() is that it is only
> available on
> Linux>2.4.11, but that dates from 2001.
> If we
> really still
> want to
> support it, we could check for that.
>
> Thoughts?
>
> Jeremy
>
>
>
>
>
More information about the hotspot-runtime-dev
mailing list