summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-08-18Add transactional ring APIDavid Robillard3-6/+113
2022-08-12Run TSan and MSan on CIDavid Robillard1-3/+6
2022-08-12Fix ring thread safetyDavid Robillard1-25/+53
The previous code was "probably fine" in practice, but was both missing some necessary synchronization, and using unnecessarily heavyweight barriers on Windows. Since this code conveniently has a 1:1 relationship between barriers and atomic accesses anyway, rewrite things to use an "atomic" interface closer to standard C11 and C++11. Harden things in the process, so that the thread-safety guarantees are followed, and hopefully clearer to see in the code (1 synchronized read of "their" index, then maybe 1 synchronized write of "your" index). Windows/MSVC annoyingly does not provide a suitable C API for this, so just ignore the existence of Windows on ARM and use x86/x64 Windows intrinsics to prevent compiler reordering (which is all that's required on those architectures). Note that MSVC can make some reordering guarantees about volatile variables, but: * Only with a certain option, /volatile:ms, which Microsoft "strongly recommend" against using. It is disabled by default (and painfully slow if enabled) on ARM. * This guarantee does not prevent reordering of access to other memory (only the volatile variables themselves), which is required by a ring buffer. So, deal with that case by using explicit read and write barriers like before, but only in the atomic abstractions. In the process, switch to more lightweight barriers, which should marginally improve performance on Windows. When MSVC adds stdatomic.h support, most of the platform-specific gunk here can go away entirely.
2022-08-12Simplify ring writing codeDavid Robillard1-6/+8
The compiler is surely smart enough to factor out these common expressions, but I find this easier to read this way anyway.
2022-08-12Use a consistent error handling styleDavid Robillard1-6/+5
2022-08-12Simplify ring space calculationsDavid Robillard1-14/+2
It isn't necessary to branch here to avoid underflow. Essentially, the way that unsigned binary integers work "automatically" does what this code was doing. Note that these expressions only work for a ring buffer that, like this one, has a power of 2 (real) size and a maximum capacity 1 less than that.
2022-08-12Document the thread semantics of every ring functionDavid Robillard1-15/+42
2022-08-12Use sensible meson setup commands in CI configurationDavid Robillard1-18/+18
2022-07-18Use consistent pkg-config descriptionDavid Robillard1-1/+1
2022-07-15Pass suppression flags explicitlyDavid Robillard1-5/+4
2022-07-15Fix shared library buildDavid Robillard1-0/+1
2022-07-14Simplify linking against static librariesDavid Robillard1-3/+5
2022-07-14Clean up meson definitionsDavid Robillard1-29/+45
2022-07-13Simplify installation instructionsDavid Robillard2-25/+2
2022-07-13Suppress new warnings in clang and clang-tidy 14David Robillard4-0/+6
2022-07-13Remove unnecessary clant configurationDavid Robillard2-5/+1
2022-06-28Fix strict release buildsDavid Robillard1-1/+1
2022-06-28Format plot.py with blackDavid Robillard1-42/+59
2022-06-28Simplify clang-tidy configurationDavid Robillard3-18/+0
2022-06-28Move zix_strerror to libraryDavid Robillard3-23/+35
2022-06-28Use uppercase integer literal suffixesDavid Robillard21-208/+201
I give in.
2022-06-28Fix whitespaceDavid Robillard4-11/+11
2022-06-28Simplify dep5 file by adding license headers where possibleDavid Robillard9-5/+25
2022-06-28Update READMEDavid Robillard2-20/+118
2022-06-28Fix build as C with MSVCDavid Robillard4-6/+4
2022-06-28Clean up build configurationDavid Robillard12-44/+94
2022-06-28Add support for building Wasm with emscriptenDavid Robillard3-4/+56
2022-06-28Fix incorrect function attributesDavid Robillard2-4/+4
The ring accessors are pure, not const, because they read pointed-to data (the ring) that may change between invocations. The BTree iter comparison is const because it only compares the values passed as parameters (although they contain pointers, they aren't dereferenced).
2022-06-28Clean up meson configurationDavid Robillard5-234/+384
2022-06-28Remove redundant includesDavid Robillard2-2/+0
This is implicitly included by <inttypes.h>.
2022-03-14Reduce default BTree test timeDavid Robillard1-1/+1
2022-03-14Fix MinGW buildDavid Robillard1-0/+2
2022-02-02Avoid fallthrough annotation on older GCC versionsDavid Robillard1-1/+1
2022-02-01Fix static build on WindowsDavid Robillard1-2/+4
2022-01-14Fix hash insertion tombstone replacement caseDavid Robillard1-0/+1
2021-12-17Suppress warning in glib headersDavid Robillard1-1/+2
This should really be done more precisely, but I can't be bothered.
2021-12-17Reduce benchmark code complexityDavid Robillard1-38/+50
2021-12-17Suppress new warnings in clang-tidy 13David Robillard6-7/+10
2021-12-17Suppress new warnings in clang 13David Robillard1-0/+10
2021-12-17Fix memory leaks in dictionary benchmarkDavid Robillard1-0/+9
2021-11-02Avoid printing configuration summary as a subprojectDavid Robillard1-1/+1
2021-10-27Gracefully handle realloc failure in benchmarkDavid Robillard1-2/+16
Not really a relevant case here, but it resolves issues found by cppcheck.
2021-10-27Be explicit about operator precedenceDavid Robillard1-1/+1
2021-10-27Fix whitespaceDavid Robillard1-1/+1
2021-10-27Compile but fail at runtime if aligned allocation is not supportedDavid Robillard1-1/+1
2021-10-27Remove unnecessary includeDavid Robillard1-1/+0
2021-10-27Improve hash table performance slightlyDavid Robillard1-6/+9
2021-10-27Fix zix_digest64() to consume all inputDavid Robillard1-5/+5
This was a copy-paste bug since the loop in zix_digest32() worked differently. As a result only the first block was considered, making the digest nearly useless for larger values. The tests didn't (and unfortunately still don't) catch this because the 64-bit digest algorithm incorporates the size itself. Fix this by changing the loop to work the same way as zix_digest32(), so hopefully something like this doesn't happen again.
2021-10-25Fix incomplete header installationDavid Robillard1-0/+3
2021-09-18Fix warnings in release builds on MacOSDavid Robillard1-2/+7
Why only MacOS? Good question!
generated by cgit v1.2.1 (git 2.18.0) at 2024-07-06 23:39:20 +0000