diff options
author | Olivier Certner <olce.palemoon@certner.fr> | 2021-01-06 11:25:27 +0100 |
---|---|---|
committer | Olivier Certner <olce.palemoon@certner.fr> | 2021-01-07 17:34:03 +0100 |
commit | f76695c1ce032b634f3e0e2a593aebdd1d49703b (patch) | |
tree | 62653f3a74e8c046d154c30e04ae978335ba9b60 /media/libvorbis/lib/vorbis_bitrate.c | |
parent | da217348d9e7fe1e22df725c3b48a149e7dd9f54 (diff) | |
download | UXP-f76695c1ce032b634f3e0e2a593aebdd1d49703b.tar UXP-f76695c1ce032b634f3e0e2a593aebdd1d49703b.tar.gz UXP-f76695c1ce032b634f3e0e2a593aebdd1d49703b.tar.lz UXP-f76695c1ce032b634f3e0e2a593aebdd1d49703b.tar.xz UXP-f76695c1ce032b634f3e0e2a593aebdd1d49703b.zip |
Issue #1699 - Part 3a: mozjemalloc: Memory barriers on 'malloc_initialized'
The barriers are here to make sure that setting 'malloc_initialized' at end of
init must be noticed later by any thread running on a different core. They are
in theory necessary in the absence of an explicit pthread lock.
What could happen is that the thread doing the initialization later spawns
other threads that could not have the updated 'malloc_initialized' value,
leading to a second initialization. This is dependent on whether OSes force a
full memory barrier before the new thread is run, which I don't know, and don't
want to bother.
This was done for FreeBSD only, for the sake of robustness. In theory, this
would be needed on Windows too.
Diffstat (limited to 'media/libvorbis/lib/vorbis_bitrate.c')
0 files changed, 0 insertions, 0 deletions