|
5675312e
|
2021-11-14T02:27:10
|
|
Fix a gcc 11 warning in src/thread.h
When building under gcc 11, there is a warning about an incompatible pointer
type, since
[`__atomic_exchange`](https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html)
does not take `volatile` pointers:
```
In file included from ../src/common.h:81,
from ../src/transports/winhttp.c:8:
../src/thread-utils.h: In function ‘git___swap’:
../src/thread-utils.h:168:9: warning: argument 3 of ‘__atomic_exchange’ discards ‘volatile’ qualifier [-Wincompatible-pointer-types]
168 | __atomic_exchange(ptr, &newval, &foundval, __ATOMIC_SEQ_CST);
| ^~~~~~~~~~~~~~~~~
```
This change drops the `volatile` qualifier so that the pointer type matches
what `__atomic_exchange` expects.
|
|
9324d16e
|
2021-11-06T16:14:47
|
|
cmake: standardize USE_THREADS and USE_NSEC
Threading can now be disabled with `USE_THREADS=OFF` instead of
`THREADSAFE=OFF` to better support the other cmake semantics.
Nanosecond support is the default _if_ we can detect it. This should be
our default always - like threads - and people can opt out explicitly.
|
|
|
74708a81
|
2020-12-20T12:45:01
|
|
Homogenize semantics for atomic-related functions
There were some subtle semantic differences between the various
implementations of atomic functions. Now they behave the same, have
tests and are better documented to avoid this from happening again in
the future.
Of note:
* The semantics chosen for `git_atomic_compare_and_swap` match
`InterlockedCompareExchangePointer`/`__sync_cal_compare_and_swap` now.
* The semantics chosen for `git_atomic_add` match
`InterlockedAdd`/`__atomic_add_fetch`.
* `git_atomic_swap` and `git_atomic_load` still have a bit of semantic
difference with the gcc builtins / msvc interlocked operations, since
they require an l-value (not a pointer). If desired, this can be
homogenized.
|
|
|
fd2d4759
|
2020-12-05T22:22:38
|
|
threads: git_tls_data to git_tlsdata
Use a no-allocation approach to the TLS data abstraction.
|
|
971b7187
|
2020-08-06T16:24:18
|
|
Implement generic TLS interface
This adds a generic TLS interface for anyone to store TLS data. It is designed to work regardless of whether threading support is built into the library or not.
Nobody in the library should directly interface with the data on the TLS struct, so it's been built to be opaque even in the library.
Requires the allocator to be initialized before use.
|
|
|
404dd024
|
2020-12-05T15:57:48
|
|
threads: rename thread files to thread.[ch]
|