Re: [Qemu-devel] [PATCH v2 1/3] qemu-tls.h: Add abstraction layer for TLS variables

[Markus Armbruster]

Andreas Färber <address@hidden> writes:

> Am 27.10.2011 13:37, schrieb Peter Maydell:
>> Add an abstraction layer for defining and using thread-local
>> variables. For the moment this is implemented only for Linux,
>> which means they can only be used in restricted circumstances.
>> The abstraction layer allows us to add POSIX and Win32 support
>> later.
>> 
>
> [Paolo's SoB missing]
>
>> Signed-off-by: Peter Maydell <address@hidden>
>> ---
>>  qemu-tls.h |   51 +++++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 files changed, 51 insertions(+), 0 deletions(-)
>>  create mode 100644 qemu-tls.h
>> 
>> diff --git a/qemu-tls.h b/qemu-tls.h
>> new file mode 100644
>> index 0000000..d96a159
>> --- /dev/null
>> +++ b/qemu-tls.h
>> @@ -0,0 +1,51 @@
>> +/*
>> + * Abstraction layer for defining and using TLS variables
>> + *
>> + * Copyright (c) 2011 Red Hat, Inc, Linaro Limited
>
> The concatenation looks kind of funny. ;)

I'd split into

 * Copyright (c) 2011 Red Hat, Inc
 * Copyright (c) 2011 Linaro Limited

>> + *
>> + * Authors:
>> + *  Paolo Bonzini <address@hidden>
>> + *  Peter Maydell <address@hidden>
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of
>> + * the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along
>> + * with this program; if not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#ifndef QEMU_TLS_GCC_H
>> +#define QEMU_TLS_GCC_H
>
> Extra _GCC. But does no harm.

Unless you file "unusual" under harm, which I happen to do :)

>> +
>> +/* Per-thread variables. Note that we only have implementations
>> + * which are really thread-local on Linux; the dummy implementations
>> + * define plain global variables.
>> + *
>> + * This means that for the moment use should be restricted to
>> + * per-VCPU variables, which are OK because:
>> + *  - the only -user mode supporting multiple VCPU threads is linux-user
>> + *  - TCG system mode is single-threaded regarding VCPUs
>> + *  - KVM system mode is multi-threaded but limited to Linux
>> + *
>> + * TODO: proper implementations via Win32 .tls sections and
>> + * POSIX pthread_getspecific.
>> + */
>> +#ifdef __linux__
>> +#define DECLARE_TLS(type, x) extern DEFINE_TLS(type, x)
>> +#define DEFINE_TLS(type, x)  __thread __typeof__(type) tls__##x
>> +#define get_tls(x)           tls__##x
>> +#else
>> +/* Dummy implementations which define plain global variables */
>> +#define DECLARE_TLS(type, x) extern DEFINE_TLS(type, x)
>> +#define DEFINE_TLS(type, x)  __typeof__(type) tls__##x
>> +#define get_tls(x)           tls__##x
>> +#endif

Any particular reason for pasting tls__ onto the identifier?

>> +
>> +#endif
[...]

I wish we'll be able to ditch these cumbersome, ugly macros in favor of
C1X threading support.  It'll probably remain a wish forever, given the
lengths we go to support systems that stubbornly refuse to update their
C programming environment for the 21st century.