On 04.04.2020 22:20, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Sat Apr 4 20:20:12 UTC 2020
>
> Modified Files:
> src/sys/compat/netbsd32: syscalls.master
> src/sys/kern: kern_exit.c kern_lwp.c sys_lwp.c syscalls.master
> src/sys/sys: lwp.h
> Added Files:
> src/tests/lib/libc/sys: t_lwp_tid.c
>
> Log Message:
> Add support for lazily generating a "global thread ID" for a LWP. This
> identifier uniquely identifies an LWP across the entire system, and will
> be used in future improvements in user-space synchronization primitives.
>
> (Test disabled and libc stub not included intentionally so as to avoid
> multiple libc version bumps.)
>
> --- src/sys/sys/lwp.h:1.204 Sat Apr 4 06:51:46 2020
> +++ src/sys/sys/lwp.h Sat Apr 4 20:20:12 2020
> @@ -1,4 +1,4 @@
> -/* $NetBSD: lwp.h,v 1.204 2020/04/04 06:51:46 maxv Exp $ */
> +/* $NetBSD: lwp.h,v 1.205 2020/04/04 20:20:12 thorpej Exp $ */
>
> /*
> * Copyright (c) 2001, 2006, 2007, 2008, 2009, 2010, 2019, 2020
> @@ -135,6 +135,24 @@ struct lwp {
> u_int l_slptime; /* l: time since last blocked */
> bool l_vforkwaiting; /* a: vfork() waiting */
>
> + /* User-space synchronization. */
> + uintptr_t l___reserved; /* reserved for future use */
> + /*
> + * The global thread ID has special locking and access
> + * considerations. Because many LWPs may never need one,
> + * global thread IDs are allocated lazily in lwp_gettid().
> + * l___tid is not bean to be accessed directly unless
> + * the accessor has specific knowledge that doing so
> + * is safe. l___tid is only assigned by the LWP itself.
> + * Once assigned, it is stable until the LWP exits.
> + * An LWP assigns its own thread ID unlocked before it
> + * reaches visibility to the rest of the system, and
> + * can access its own thread ID unlocked. But once
> + * published, it must hold the proc's lock to change
> + * the value.
> + */
> + lwpid_t l___tid; /* p: global thread id */
> +
Would it be possible to keep a global unique TID as 64-bit integer
(int64_t) equal to: pid << 32 | lwpid ?
That way we could have predicatable numbers in the system and possibly
simplify the involved code avoiding one extra unique 32-bit id.
Are there any (atomic?) shortcomings of this approach?
Attachment:
signature.asc
Description: OpenPGP digital signature