We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4196 - _ReadWriteBarrier is deprecated, use atomic_thread_fence instead
Summary: _ReadWriteBarrier is deprecated, use atomic_thread_fence instead
Status: RESOLVED WONTFIX
Alias: None
Product: SDL
Classification: Unclassified
Component: atomic (show other bugs)
Version: don't know
Hardware: All Windows (All)
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-09 04:37 UTC by Coriiander
Modified: 2019-06-14 00:09 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Coriiander 2018-06-09 04:37:56 UTC 
Hello,

This message is with regards to compiler/memory barriers for the Windows platform.

In various parts throughout the SDL-code the _ReadWriteBarrier intrinsic is used. (e.g. in SDL_atomic.h, SDL_atomic.c and SDL_spinlock.c) Either through _ReadWriteBarrier or through various macros that evaluate to _ReadWriteBarrier (e.g. SDL_CompilerBarrier, SDL_MemoryBarrierAcquire and SDL_MemoryBarrierRelease).

I would like to point out that the _ReadWriteBarrier intrinsic has been deprecated for quite a while now and should not be used. To quote from MSDN:

The _ReadBarrier, _WriteBarrier, and _ReadWriteBarrier compiler intrinsics and the MemoryBarrier macro are all deprecated and should not be used. For inter-thread communication, use mechanisms such as atomic_thread_fence and std::atomic<T>, which are defined in the C++ Standard Library. For hardware access, use the /volatile:iso compiler option together with the volatile keyword.

MSDN-link:
https://msdn.microsoft.com/en-us/library/f20w0x5e.aspx?f=255&MSPPError=-2147217396



Cheers,
Cor Schols, alias Coriiander
Comment 1 Sam Lantinga 2019-06-12 15:29:38 UTC 
SDL is a C library, are there equivalent mechanisms for C libraries?
Comment 2 Sam Lantinga 2019-06-12 15:31:36 UTC 
Sorry, to be clear, SDL supports building without any C runtime to avoid C runtime issues on Windows. Is there a way to use atomic_thread_fence in this configuration?
Comment 3 Coriiander 2019-06-13 01:05:10 UTC 
(In reply to Sam Lantinga from comment #2)
> Sorry, to be clear, SDL supports building without any C runtime to avoid C
> runtime issues on Windows. Is there a way to use atomic_thread_fence in this
> configuration?

Yes, that's clear and a core value for SDL. Unfortuntely I don't know of a Microsoft-provided replacement for the deprecated APIs for C. It is an evergrowing problem with the provided Microsoft APIs, as in they're moving evermore away from providing usable C-interfaces.

Alternatives would be:
- keep using deprecated intrinsics;
- use build-time opt-in C++ implementation with custom public C interface;
- use generic fallback logic;
- provide architecture-specific assembler implementations (probably a no go);

As I cannot bring in a solution, I perhaps should not have filed the ticket. It's just that building forth upon deprecated matter feels wrong.
Comment 4 Sam Lantinga 2019-06-14 00:09:43 UTC 
I agree. It sounds like for now, continuing to use the intrinsics is our best option. Feel free to reopen this bug if you have more ideas.