Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Jul 2013 00:34:58 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Davide Italiano <davide@freebsd.org>
Cc:        freebsd-amd64@freebsd.org, freebsd-threads@freebsd.org
Subject:   Re: Accessing struct pthread from kernel
Message-ID:  <20130707213458.GH91021@kib.kiev.ua>
In-Reply-To: <CACYV=-H_T98QPWOLS=0iHxgt1Om-sR3p8ogqFCsZHFiZDLtosg@mail.gmail.com>
References:  <CACYV=-H_T98QPWOLS=0iHxgt1Om-sR3p8ogqFCsZHFiZDLtosg@mail.gmail.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

--KUl1BpUVukgrQ7uD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 06, 2013 at 01:22:05AM +0200, Davide Italiano wrote:
> Hi,
> as a preliminary step in the implementation of adaptive spinning for
> umtx, I'm switching the pthread/umtx code so that a thread that
> acquires a pthread_mutex writes the address of struct pthread in the
> owner field of the lock instead of the thread id (tid). This is
> because having struct pthread pointer allows easily to access
> informations of the thread, and makes easy to get the state of the
> thread exported from the kernel (once this will be implemented).
>=20
> For what concerns the libthr side, the internal function
> _get_curthread() goes into the TLS to obtain the struct field of
> curthread, so I'm done.
> OTOH, I'm quite unsure instead about how to get address of struct
> pthread for curthread from the kernel side (for example, in
> do_lock_umutex() sys/kern/kern_umtx.c).
You should not, see below.

>=20
> I guess I need to write some MD code because the TLS is different on
> the various architecture supported in FreeBSD, and as a first step I
> focused on amd64.
> It looks like from the SDM that %%fs register points to the base of
> the TLS, so I think that accessing using curthread->td_pcb->pcb_fsbase
> (and then adding the proper offset to acces the right field) is a
> viable solution to do this. Am I correct?
> In particular what worries me is if the read of 'struct pthread' for
> curthread from the TLS register is atomic with respect to preemptions.
>=20
> Alternatively, is there an (easier way) to accomplish this task?

Coupling the libthr thread structure and kernel makes the ABI cast in
stone and avoids most possibilities of changing the libthr internals.
The same is true for kernel accessing the userspace TLS area of the thread.

If you want kernel<->usermode communication of the thread run state,
and possibly also a way to advisory prevent a preemption of the
spinning usermode thread, you should create a dedicated parameter block
communicated from usermode to kernel on thread creation. For the main
thread, the block could be allocated by kernel by image activator,
placed on the stack and its address passed to the usermode by auxv.

Note that you cannot access the usermode from the context switch
code. Wiring the corresponding page is very wasteful (think about a
process with 10,000 threads) and still does not provide any guarantees
since usermode can unmap or remap the range. You might see my 'fast
sigprocmask' patches where somewhat similar idea was implemented.

I also recommend you to look at the Solaris schedctl(2).

--KUl1BpUVukgrQ7uD
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (FreeBSD)

iQIcBAEBAgAGBQJR2d8BAAoJEJDCuSvBvK1B2eMP/3wSALXdp5FSZb407N2oD6d/
9vbhDnwRa5wMt5qzlktX7HSTUMsRjUSMyS7PfR7nLXp6/G5UKfQ/uBMR/R+J5bVs
Z8nyIJ6tzE5+sYiAeWOzRI1tYk8K2uaC8lKeDB0NiVg0M1EaBRQMsJ894UJ9bhJq
71EC3YrS/WNl8KJKKZAoWP/ZR/aOtXbqZ7c69A7PC9yLvfp1oxtWbXoEBNNLx+UZ
y3zf0TAyaWCpafl78Ftpb8ZGL3LaULR97JDYnachXVP0ATGVchDee10W3D/6FnBT
cdI9mQ5hBYcAbC6pAz1gkotBDNeqGau6rneaCosSiehJmpVDTHTBLLey05SW3MWR
0ND9rwoQJvDcpWyPSVFx5ubcYQMXZ5wM1r0Us4znIELy4IXm5PArAnyN5nJVfKx+
SfPUNAAJz8eXybkFufnpdHavqaMyvetBjQ+20VdpI1hxtgIZXE8KHfYpAHl53Ozp
pINKqlnZKLScjjWVOcQEHqwSPZYAYIuVBRcuCh23cYteBS5FDr4uGLIHQZ7usP0l
Z1LhuVe6y+eMPSosI8AyCl9crcQHHIzTb7utHP9FzHVNXBkDj2XL+XgE1HL9+cEY
l1rPg3hBnxyH4yzD8gQnMAJTeWQTUUb89CDT9FLi20YgyiWFpOh/Uh3yfmFc9xan
JMA232G6Ic8crBLbFU2i
=T71R
-----END PGP SIGNATURE-----

--KUl1BpUVukgrQ7uD--



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20130707213458.GH91021>