Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
Note about Multi-threading
Avatar
W Pirkle
Admin
October 14, 2019 - 12:53 pm
Member Since: January 28, 2017
Forum Posts: 358
sp_UserOfflineSmall Offline

In the new FX book, there is a section on multithreading, especially involving corrupted data and race conditions. With RackAFX7, which is still 32-bit, this is an issue and I updated the API back in 2015 to address this. In the book, I use 64-bit values in the examples that discuss reading and writing partial values on thread slice boundaries. I got a really great email from a book reader today who pointed out that for 64-bit data, there is built-in atomic guarantees for data. This is most of the email he sent, along with a link for more information. I hope it helps clear up any misunderstandings. I still have threading issues in 32-bit plugins and processing. 

Quote from email:

"I think that your description of the issues surrounding multithreaded reads and writes is somewhat misleading. On a 64-bit operating system, writing ints, longs, floats and doubles is atomic in the sense that no matter how hard you try, if you concurrently write X and Y then you are guaranteed to read either X or Y, but not some corrupted combination of the two. This is because these types are all aligned to the 64-bit memory boundary and the cache line reads in 64 byte chunks, not 8 byte chunks as you suggest. The arbitrary nature of the read occurs from the fact that each thread may hold its own copy of the value, so a synchronisation mechanism is required to ensure that all threads synchronise their copy prior to accessing the variable. I think in the situation you describe of a single primitive value the worst that will happen is that the plugin slightly lags behind the DAW. For a genuinely corrupt state to occur you need either a non-primitive value, such as a string, or multiple primitive values. Specifically the data need to span the 64-bit memory boundary.

Of course on a 32-bit OS corruption of doubles and longs is possible as the cache line is only 32-bytes.

This blog post is relevant: https://codywu2010.wordpress.com/2014/11/03/is-int-write-operation-atomic-on-x86_64/ 

 

 

Forum Timezone: America/New_York

Most Users Ever Online: 78

Currently Online:
6 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

Skyler: 48

Derek: 46

Frodson: 45

TheSmile: 43

Peter: 41

clau_ste: 39

JimmyM: 33

Gwen: 32

EZB: 24

lppier: 23

Member Stats:

Guest Posters: 1

Members: 575

Moderators: 1

Admins: 4

Forum Stats:

Groups: 12

Forums: 36

Topics: 593

Posts: 2366

Newest Members:

acv, Vasil992, Vasil92, dowsed, Simple, Chris_1, manyu, AdamR, Stuart, Al Calabrese

Moderators: W Pirkle: 358

Administrators: Tom: 73, JD Young: 80, Will Pirkle: 0, W Pirkle: 358