| Summary: | Use C++11 atomic intrinsics | ||
|---|---|---|---|
| Product: | HarfBuzz | Reporter: | Behdad Esfahbod <freedesktop> |
| Component: | src | Assignee: | Behdad Esfahbod <freedesktop> |
| Status: | RESOLVED MOVED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | freedesktop, froydnj |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | harfbuzz-atomics.patch | ||
|
Description
Behdad Esfahbod
2015-05-04 18:13:55 UTC
Created attachment 115603 [details] [review] harfbuzz-atomics.patch Here's something that seems to work for me Thanks. Are these able to replace pthreads mutex implementation as well? I'm assuming you mean the bits in hb-mutex-private.hh? I suppose we could write something for HAVE_CXX11_ATOMIC_PRIMITIVES, but I'm not sure it makes a big difference: such a case is only hit on a non-Windows system with threads (but not pthreads) and a GCC-esque compiler...seems like kind of an unusual system. The argument for making the hb-atomic-private.hh changes was to fix hb_atomic_ptr_impl_get so that the atomicity of the load was visible to TSan or similar. There's not an equivalent case here; the interesting accesses are both fully covered by the __sync_* operations. Makes sense. Thanks. FWIW, I always wondered about the cryptic way the atomic get/set were implemented. Following up here: https://github.com/behdad/harfbuzz/issues/345 |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.