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