# AudioBuffer\<\> and its clear flag

**URL:** <https://forum.juce.com/t/audiobuffer-and-its-clear-flag/40190>\
**Category:** General JUCE discussion\
**Created:** [June 18, 2020, 6:00am UTC](https://forum.juce.com/t/audiobuffer-and-its-clear-flag/40190 "2020-06-18T06:00:30Z")\
**Posts on this page:** 1\
**Showing post:** 55

<div class="post-metadata">

**Author:** ![ed95](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ed95/32/7635_2.png) [@ed95](https://forum.juce.com/u/ed95)\
**Post date:** [August 16, 2021, 5:09pm UTC](https://forum.juce.com/t/audiobuffer-and-its-clear-flag/40190/55 "2021-08-16T17:09:28Z")

</div>

Apologies for taking a while to respond to this, I wanted to get the rest of the team’s input before making any changes.

The original forum thread that lead to this change was here:

> [@Thread Sanitizer detects a data race in AudioThumbnail](https://forum.juce.com/t/thread-sanitizer-detects-a-data-race-in-audiothumbnail/32470):
>
> In latest develop (c96bf71488a), running the JUCE demo’s audio player demo with Thread Sanitizer (“Xcode/Edit Scheme/Run/Diagnostics/Thread Sanitizer”), when opening an audio file - A data race is detected at AudioThumbnail::setLevels where it updates totalSamples. (my env: Xcode 10.1, macOS 10.14.3) This may be benign (am not familiar with the code) but I think that it’s good practice to either solve the race or mark it as benign, so people could use the invaluable Thread Sanitizer without t…

and the “fix” that I pushed was to make the `AudioBuffer::isClear` flag atomic which silenced tsan but clearly had some unintended side effects.

Given that `AudioBuffer` makes no guarantees about thread safety and contains no other synchronisation I don’t think it should be the responsibility of the class to be thread safe. Making `isClear` atomic also doesn’t make it thread safe since some higher level synchronisation would be required to actually guard the clearing and filling of the audio data, it just makes tsan happy.

I’ve reverted that change and made `isClear` a plain old `bool` here:

> <https://github.com/juce-framework/JUCE/commit/832deb9ad7dcf4f44858233b2a3d4f05a69f4d18>

and I’ve pushed a fix for the actual problem in `BufferingAudioSource` here:

> <https://github.com/juce-framework/JUCE/commit/80602649a2d3c86de7e85b335f7b6290700c4bc0>

---

_[View the full topic](https://forum.juce.com/t/audiobuffer-and-its-clear-flag/40190)._