Confusing memory orderings for MAX_LOG_LEVEL_FILTER #453

New issue

Closed

opened 2021-05-03 18:18:53 -05:00 by nico-abram · 1 comment

nico-abram commented

2021-05-03 18:18:53 -05:00

(Migrated from github.com)

Skimming the code for lib.rs, I see the log level is a global atomic:

static MAX_LOG_LEVEL_FILTER: AtomicUsize = AtomicUsize::new(0);

I'm opening this issue because, as I understand it, the memory orderings used for the store/loads to this variable in this file make no sense:

SeqCst is used for the store:

pub fn set_max_level(level: LevelFilter) {
    MAX_LOG_LEVEL_FILTER.store(level as usize, Ordering::SeqCst)
}

Relaxed is used for the load:

pub fn max_level() -> LevelFilter {
    // Since `LevelFilter` is `repr(usize)`,
    // this transmute is sound if and only if `MAX_LOG_LEVEL_FILTER`
    // is set to a usize that is a valid discriminant for `LevelFilter`.
    // Since `MAX_LOG_LEVEL_FILTER` is private, the only time it's set
    // is by `set_max_level` above, i.e. by casting a `LevelFilter` to `usize`.
    // So any usize stored in `MAX_LOG_LEVEL_FILTER` is a valid discriminant.
    unsafe { mem::transmute(MAX_LOG_LEVEL_FILTER.load(Ordering::Relaxed)) }
}

AIUI, this means the SeqCst store is not synchronizing with any SeqCst loads, so it is useless. Shouldn't the store also be relaxed (To match what I understand are the current semantics being used), or the load be made SeqCst (To change from the current Relaxed semantics to SeqCst)?

I found this PR which favors using SeqCst everywhere except where it's perf-critical, is the (confusing, and seemingly AFAIK useless since it's not synchronizing with any SeqCst load) SeqCst store intended?

The current load/store pairs seem confusing to me because it's not clear if the semantics desired are Relaxed (In which case the SeqCst store should not be there), or SeqCst (In which case there is currently a bug because of the Relaxed load)

Skimming the code for [lib.rs](https://github.com/rust-lang/log/blob/master/src/lib.rs), I see the log level is a global atomic: ```rs static MAX_LOG_LEVEL_FILTER: AtomicUsize = AtomicUsize::new(0); ``` I'm opening this issue because, as I understand it, the memory orderings used for the store/loads to this variable in this file make no sense: SeqCst is used for the store: ```rs pub fn set_max_level(level: LevelFilter) { MAX_LOG_LEVEL_FILTER.store(level as usize, Ordering::SeqCst) } ``` Relaxed is used for the load: ```rs pub fn max_level() -> LevelFilter { // Since `LevelFilter` is `repr(usize)`, // this transmute is sound if and only if `MAX_LOG_LEVEL_FILTER` // is set to a usize that is a valid discriminant for `LevelFilter`. // Since `MAX_LOG_LEVEL_FILTER` is private, the only time it's set // is by `set_max_level` above, i.e. by casting a `LevelFilter` to `usize`. // So any usize stored in `MAX_LOG_LEVEL_FILTER` is a valid discriminant. unsafe { mem::transmute(MAX_LOG_LEVEL_FILTER.load(Ordering::Relaxed)) } } ``` AIUI, this means the SeqCst store is not synchronizing with any SeqCst loads, so it is useless. Shouldn't the store also be relaxed (To match what I understand are the current semantics being used), or the load be made SeqCst (To change from the current Relaxed semantics to SeqCst)? I found [this PR](https://github.com/rust-lang/log/pull/12) which favors using SeqCst everywhere except where it's perf-critical, is the (confusing, and seemingly AFAIK useless since it's not synchronizing with any SeqCst load) SeqCst store intended? The current load/store pairs seem confusing to me because it's not clear if the semantics desired are Relaxed (In which case the SeqCst store should not be there), or SeqCst (In which case there is currently a bug because of the Relaxed load)

sfackler commented

2021-05-03 18:30:03 -05:00

(Migrated from github.com)