Simplify and fix AtomicCounter

[TheBlueMatt]

AtomicCounter was slightly race-y on 32-bit platforms because it
increments the high AtomicUsize independently from the low
AtomicUsize, leading to a potential race where another thread
could observe the low increment but not the high increment and see
a value of 0 twice.

This isn't a big deal because (a) most platforms are 64-bit these
days, (b) 32-bit platforms aren't super likely to have their
counter overflow 32 bits anyway, and (c) the two writes are
back-to-back so having another thread read during that window is
very unlikely.

However, we can also optimize the counter somewhat by using the
target_has_atomic = "64" cfg flag, which we do here, allowing us
to use AtomicU64 even on 32-bit platforms where 64-bit atomics
are available.

This changes some test behavior slightly, which requires
adaptation.

Fixes#3000

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.57%. Comparing base (d35239c) to head (1c2bd09).
Report is 33 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3302 +/- ##
==========================================
+ Coverage 89.85% 90.57% +0.72% 
==========================================
Files 126 126 Lines 104145 109040 +4895 Branches 104145 109040 +4895 ==========================================
+ Hits 93577 98761 +5184 + Misses 7894 7624 -270 + Partials 2674 2655 -19 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tnull]

nit: Preexisting, this naming seems a bit confusing as we're actually not returning the incremented counter. Maybe the field should be called next_counter and the method just next()?

[tnull]

LGTM, I think. Feel free to squash the fixup.

[TheBlueMatt]

Squashed.

[tnull]

Squashed.

It seems you're missing some imports here, CI is sad:

error[E0412]: cannot find type `Mutex` in this scope
--> /home/runner/work/rust-lightning/rust-lightning/lightning/src/util/atomic_counter.rs:13:11
|
13 | counter: Mutex<u64>,
| ^^^^^ not found in this scope
|
help: consider importing this struct through its public re-export
|
5 + use crate::sync::Mutex;
|

etc

[TheBlueMatt]

Gah

$ git diff-tree -U1 7b1f07bd3 38ecd35c7
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index d00c7341b..6dbe54e64 100644
--- a/lightning/src/util/atomic_counter.rs+++ b/lightning/src/util/atomic_counter.rs@@ -5,3 +5,3 @@ use core::sync::atomic::{AtomicU64, Ordering};
#[cfg(not(target_has_atomic = "64"))]
-use crate::prelude::*;+use crate::sync::Mutex;
$ 

[tnull]

LGTM, happy to land it if CI passes.

[TheBlueMatt]

FFS

$ git diff-tree -U1 38ecd35c7 dccdd3c15
diff --git a/lightning/src/sign/mod.rs b/lightning/src/sign/mod.rs
index 41354c695..4b8a9e025 100644
--- a/lightning/src/sign/mod.rs+++ b/lightning/src/sign/mod.rs@@ -1029,3 +1029,2 @@ pub trait ChangeDestinationSource {
/// a secure external signer.
-#[derive(Debug)]
pub struct InMemorySigner {
@@ -2483,3 +2482,2 @@ impl PhantomKeysManager {
/// An implementation of [`EntropySource`] using ChaCha20.
-#[derive(Debug)]
pub struct RandomBytes {
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index 6dbe54e64..3627ccf8a 100644
--- a/lightning/src/util/atomic_counter.rs+++ b/lightning/src/util/atomic_counter.rs@@ -7,3 +7,2 @@ use crate::sync::Mutex;
-#[derive(Debug)]
pub(crate) struct AtomicCounter {
$ 

[tnull]

FFS

Nope:

error[E0596]: cannot borrow `mtx` as mutable, as it is not declared as mutable
--> /home/runner/work/rust-lightning/rust-lightning/lightning/src/util/atomic_counter.rs:30:5
|
30 | *mtx += 1;
| ^^^ cannot borrow as mutable
|
help: consider changing this to be mutable
|
29 | let mut mtx = self.counter.lock().unwrap();
| +++
For more information about this error, try `rustc --explain E0596`.
warning: `lightning` (lib) generated 1 warning
error: could not compile `lightning` (lib) due to 1 previous error; 1 warning emitted
Error: Process completed with exit code 101.

[TheBlueMatt]

Grr, guess I didn't have the arm compiler installed so running CI locally didn't test it...

$ git diff-tree -U2 dccdd3c15 68d4c9673
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index 3627ccf8a..b1fd7323f 100644
--- a/lightning/src/util/atomic_counter.rs
+++ b/lightning/src/util/atomic_counter.rs
@@ -38,5 +38,5 @@ impl AtomicCounter {
}
#[cfg(not(target_has_atomic = "64"))] {
- let mtx = self.counter.lock().unwrap();
+ let mut mtx = self.counter.lock().unwrap();
*mtx = count;
}
$ 

[tnull]

LGTM, landing this as pretty trivial.

[Kixunil]

If the intention is to produce some unique values that maybe don't need to be sequential you can still have a sensible lock-free implementation. Roughly like this:

letmut low = self.low.load(Relaxed);letmut high = self.high.load(Relaxed);loop{let new_low = if low == u32::MAX{// don't use fetch_add to avoid incrementing high by more than 1ifletErr(new) = self.high.compare_exchange(high, high + 1,Relaxed,Relaxed){
high = new;}0}else{
low + 1}// FTR this cannot be weakmatchself.low.compare_exchange(low, new_low,Relaxed,Relaxed){Ok(_) => break,Err(new) => low = new,}}
u64::from(high) << 32 | u64::from(low)

This assumes that a thread doesn't get scheduled-out after incrementing high for so long that other thread(s) manage to increment the counter by 2^32, which I think is a reasonable assumption. There's still a chance that high gets bumped by more than one though if a thread managed to bump it and before it updates low another thread reads both of them. This is quite unfrequent and could be dealt with by sacrificing one bit of high which gets set first and then reset at the end.

[Kixunil]

You have AcqRel however to my understanding this is not a synchronization primitive so Relaxed is appropriate.

[TheBlueMatt]

AtomicCounter was slightly race-y on 32-bit platforms because it
increments the high AtomicUsize independently from the low
AtomicUsize, leading to a potential race where another thread
could observe the low increment but not the high increment and see
a value of 0 twice.

This isn't a big deal because (a) most platforms are 64-bit these
days, (b) 32-bit platforms aren't super likely to have their
counter overflow 32 bits anyway, and (c) the two writes are
back-to-back so having another thread read during that window is
very unlikely.

However, we can also optimize the counter somewhat by using the
target_has_atomic = "64" cfg flag, which we do here, allowing us
to use AtomicU64 even on 32-bit platforms where 64-bit atomics
are available.

This changes some test behavior slightly, which requires
adaptation.

Fixes#3000

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.57%. Comparing base (d35239c) to head (1c2bd09).
Report is 33 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3302 +/- ##
==========================================
+ Coverage 89.85% 90.57% +0.72% 
==========================================
Files 126 126 Lines 104145 109040 +4895 Branches 104145 109040 +4895 ==========================================
+ Hits 93577 98761 +5184 + Misses 7894 7624 -270 + Partials 2674 2655 -19 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tnull]

nit: Preexisting, this naming seems a bit confusing as we're actually not returning the incremented counter. Maybe the field should be called next_counter and the method just next()?

[tnull]

LGTM, I think. Feel free to squash the fixup.

[TheBlueMatt]

Squashed.

[tnull]

Squashed.

It seems you're missing some imports here, CI is sad:

error[E0412]: cannot find type `Mutex` in this scope
--> /home/runner/work/rust-lightning/rust-lightning/lightning/src/util/atomic_counter.rs:13:11
|
13 | counter: Mutex<u64>,
| ^^^^^ not found in this scope
|
help: consider importing this struct through its public re-export
|
5 + use crate::sync::Mutex;
|

etc

[TheBlueMatt]

Gah

$ git diff-tree -U1 7b1f07bd3 38ecd35c7
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index d00c7341b..6dbe54e64 100644
--- a/lightning/src/util/atomic_counter.rs+++ b/lightning/src/util/atomic_counter.rs@@ -5,3 +5,3 @@ use core::sync::atomic::{AtomicU64, Ordering};
#[cfg(not(target_has_atomic = "64"))]
-use crate::prelude::*;+use crate::sync::Mutex;
$ 

[tnull]

LGTM, happy to land it if CI passes.

[TheBlueMatt]

FFS

$ git diff-tree -U1 38ecd35c7 dccdd3c15
diff --git a/lightning/src/sign/mod.rs b/lightning/src/sign/mod.rs
index 41354c695..4b8a9e025 100644
--- a/lightning/src/sign/mod.rs+++ b/lightning/src/sign/mod.rs@@ -1029,3 +1029,2 @@ pub trait ChangeDestinationSource {
/// a secure external signer.
-#[derive(Debug)]
pub struct InMemorySigner {
@@ -2483,3 +2482,2 @@ impl PhantomKeysManager {
/// An implementation of [`EntropySource`] using ChaCha20.
-#[derive(Debug)]
pub struct RandomBytes {
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index 6dbe54e64..3627ccf8a 100644
--- a/lightning/src/util/atomic_counter.rs+++ b/lightning/src/util/atomic_counter.rs@@ -7,3 +7,2 @@ use crate::sync::Mutex;
-#[derive(Debug)]
pub(crate) struct AtomicCounter {
$ 

[tnull]

FFS

Nope:

error[E0596]: cannot borrow `mtx` as mutable, as it is not declared as mutable
--> /home/runner/work/rust-lightning/rust-lightning/lightning/src/util/atomic_counter.rs:30:5
|
30 | *mtx += 1;
| ^^^ cannot borrow as mutable
|
help: consider changing this to be mutable
|
29 | let mut mtx = self.counter.lock().unwrap();
| +++
For more information about this error, try `rustc --explain E0596`.
warning: `lightning` (lib) generated 1 warning
error: could not compile `lightning` (lib) due to 1 previous error; 1 warning emitted
Error: Process completed with exit code 101.

[TheBlueMatt]

Grr, guess I didn't have the arm compiler installed so running CI locally didn't test it...

$ git diff-tree -U2 dccdd3c15 68d4c9673
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index 3627ccf8a..b1fd7323f 100644
--- a/lightning/src/util/atomic_counter.rs
+++ b/lightning/src/util/atomic_counter.rs
@@ -38,5 +38,5 @@ impl AtomicCounter {
}
#[cfg(not(target_has_atomic = "64"))] {
- let mtx = self.counter.lock().unwrap();
+ let mut mtx = self.counter.lock().unwrap();
*mtx = count;
}
$ 

[tnull]

LGTM, landing this as pretty trivial.

[Kixunil]

If the intention is to produce some unique values that maybe don't need to be sequential you can still have a sensible lock-free implementation. Roughly like this:

letmut low = self.low.load(Relaxed);letmut high = self.high.load(Relaxed);loop{let new_low = if low == u32::MAX{// don't use fetch_add to avoid incrementing high by more than 1ifletErr(new) = self.high.compare_exchange(high, high + 1,Relaxed,Relaxed){
high = new;}0}else{
low + 1}// FTR this cannot be weakmatchself.low.compare_exchange(low, new_low,Relaxed,Relaxed){Ok(_) => break,Err(new) => low = new,}}
u64::from(high) << 32 | u64::from(low)

This assumes that a thread doesn't get scheduled-out after incrementing high for so long that other thread(s) manage to increment the counter by 2^32, which I think is a reasonable assumption. There's still a chance that high gets bumped by more than one though if a thread managed to bump it and before it updates low another thread reads both of them. This is quite unfrequent and could be dealt with by sacrificing one bit of high which gets set first and then reset at the end.

[Kixunil]

You have AcqRel however to my understanding this is not a synchronization primitive so Relaxed is appropriate.

[TheBlueMatt]

AtomicCounter was slightly race-y on 32-bit platforms because it
increments the high AtomicUsize independently from the low
AtomicUsize, leading to a potential race where another thread
could observe the low increment but not the high increment and see
a value of 0 twice.

This isn't a big deal because (a) most platforms are 64-bit these
days, (b) 32-bit platforms aren't super likely to have their
counter overflow 32 bits anyway, and (c) the two writes are
back-to-back so having another thread read during that window is
very unlikely.

However, we can also optimize the counter somewhat by using the
target_has_atomic = "64" cfg flag, which we do here, allowing us
to use AtomicU64 even on 32-bit platforms where 64-bit atomics
are available.

This changes some test behavior slightly, which requires
adaptation.

Fixes#3000

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.57%. Comparing base (d35239c) to head (1c2bd09).
Report is 33 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3302 +/- ##
==========================================
+ Coverage 89.85% 90.57% +0.72% 
==========================================
Files 126 126 Lines 104145 109040 +4895 Branches 104145 109040 +4895 ==========================================
+ Hits 93577 98761 +5184 + Misses 7894 7624 -270 + Partials 2674 2655 -19 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tnull]

nit: Preexisting, this naming seems a bit confusing as we're actually not returning the incremented counter. Maybe the field should be called next_counter and the method just next()?

[tnull]

LGTM, I think. Feel free to squash the fixup.

[TheBlueMatt]

Squashed.

[tnull]

Squashed.

It seems you're missing some imports here, CI is sad:

error[E0412]: cannot find type `Mutex` in this scope
--> /home/runner/work/rust-lightning/rust-lightning/lightning/src/util/atomic_counter.rs:13:11
|
13 | counter: Mutex<u64>,
| ^^^^^ not found in this scope
|
help: consider importing this struct through its public re-export
|
5 + use crate::sync::Mutex;
|

etc

[TheBlueMatt]

Gah

$ git diff-tree -U1 7b1f07bd3 38ecd35c7
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index d00c7341b..6dbe54e64 100644
--- a/lightning/src/util/atomic_counter.rs+++ b/lightning/src/util/atomic_counter.rs@@ -5,3 +5,3 @@ use core::sync::atomic::{AtomicU64, Ordering};
#[cfg(not(target_has_atomic = "64"))]
-use crate::prelude::*;+use crate::sync::Mutex;
$ 

[tnull]

LGTM, happy to land it if CI passes.

[TheBlueMatt]

FFS

$ git diff-tree -U1 38ecd35c7 dccdd3c15
diff --git a/lightning/src/sign/mod.rs b/lightning/src/sign/mod.rs
index 41354c695..4b8a9e025 100644
--- a/lightning/src/sign/mod.rs+++ b/lightning/src/sign/mod.rs@@ -1029,3 +1029,2 @@ pub trait ChangeDestinationSource {
/// a secure external signer.
-#[derive(Debug)]
pub struct InMemorySigner {
@@ -2483,3 +2482,2 @@ impl PhantomKeysManager {
/// An implementation of [`EntropySource`] using ChaCha20.
-#[derive(Debug)]
pub struct RandomBytes {
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index 6dbe54e64..3627ccf8a 100644
--- a/lightning/src/util/atomic_counter.rs+++ b/lightning/src/util/atomic_counter.rs@@ -7,3 +7,2 @@ use crate::sync::Mutex;
-#[derive(Debug)]
pub(crate) struct AtomicCounter {
$ 

[tnull]

FFS

Nope:

error[E0596]: cannot borrow `mtx` as mutable, as it is not declared as mutable
--> /home/runner/work/rust-lightning/rust-lightning/lightning/src/util/atomic_counter.rs:30:5
|
30 | *mtx += 1;
| ^^^ cannot borrow as mutable
|
help: consider changing this to be mutable
|
29 | let mut mtx = self.counter.lock().unwrap();
| +++
For more information about this error, try `rustc --explain E0596`.
warning: `lightning` (lib) generated 1 warning
error: could not compile `lightning` (lib) due to 1 previous error; 1 warning emitted
Error: Process completed with exit code 101.

[TheBlueMatt]

Grr, guess I didn't have the arm compiler installed so running CI locally didn't test it...

$ git diff-tree -U2 dccdd3c15 68d4c9673
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index 3627ccf8a..b1fd7323f 100644
--- a/lightning/src/util/atomic_counter.rs
+++ b/lightning/src/util/atomic_counter.rs
@@ -38,5 +38,5 @@ impl AtomicCounter {
}
#[cfg(not(target_has_atomic = "64"))] {
- let mtx = self.counter.lock().unwrap();
+ let mut mtx = self.counter.lock().unwrap();
*mtx = count;
}
$ 

[tnull]

LGTM, landing this as pretty trivial.

[Kixunil]

If the intention is to produce some unique values that maybe don't need to be sequential you can still have a sensible lock-free implementation. Roughly like this:

letmut low = self.low.load(Relaxed);letmut high = self.high.load(Relaxed);loop{let new_low = if low == u32::MAX{// don't use fetch_add to avoid incrementing high by more than 1ifletErr(new) = self.high.compare_exchange(high, high + 1,Relaxed,Relaxed){
high = new;}0}else{
low + 1}// FTR this cannot be weakmatchself.low.compare_exchange(low, new_low,Relaxed,Relaxed){Ok(_) => break,Err(new) => low = new,}}
u64::from(high) << 32 | u64::from(low)

This assumes that a thread doesn't get scheduled-out after incrementing high for so long that other thread(s) manage to increment the counter by 2^32, which I think is a reasonable assumption. There's still a chance that high gets bumped by more than one though if a thread managed to bump it and before it updates low another thread reads both of them. This is quite unfrequent and could be dealt with by sacrificing one bit of high which gets set first and then reset at the end.

[Kixunil]

You have AcqRel however to my understanding this is not a synchronization primitive so Relaxed is appropriate.

[TheBlueMatt]

AtomicCounter was slightly race-y on 32-bit platforms because it
increments the high AtomicUsize independently from the low
AtomicUsize, leading to a potential race where another thread
could observe the low increment but not the high increment and see
a value of 0 twice.

This isn't a big deal because (a) most platforms are 64-bit these
days, (b) 32-bit platforms aren't super likely to have their
counter overflow 32 bits anyway, and (c) the two writes are
back-to-back so having another thread read during that window is
very unlikely.

However, we can also optimize the counter somewhat by using the
target_has_atomic = "64" cfg flag, which we do here, allowing us
to use AtomicU64 even on 32-bit platforms where 64-bit atomics
are available.

This changes some test behavior slightly, which requires
adaptation.

Fixes#3000

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.57%. Comparing base (d35239c) to head (1c2bd09).
Report is 33 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3302 +/- ##
==========================================
+ Coverage 89.85% 90.57% +0.72% 
==========================================
Files 126 126 Lines 104145 109040 +4895 Branches 104145 109040 +4895 ==========================================
+ Hits 93577 98761 +5184 + Misses 7894 7624 -270 + Partials 2674 2655 -19 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tnull]

nit: Preexisting, this naming seems a bit confusing as we're actually not returning the incremented counter. Maybe the field should be called next_counter and the method just next()?

[tnull]

LGTM, I think. Feel free to squash the fixup.

[TheBlueMatt]

Squashed.

[tnull]

Squashed.

It seems you're missing some imports here, CI is sad:

error[E0412]: cannot find type `Mutex` in this scope
--> /home/runner/work/rust-lightning/rust-lightning/lightning/src/util/atomic_counter.rs:13:11
|
13 | counter: Mutex<u64>,
| ^^^^^ not found in this scope
|
help: consider importing this struct through its public re-export
|
5 + use crate::sync::Mutex;
|

etc

[TheBlueMatt]

Gah

$ git diff-tree -U1 7b1f07bd3 38ecd35c7
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index d00c7341b..6dbe54e64 100644
--- a/lightning/src/util/atomic_counter.rs+++ b/lightning/src/util/atomic_counter.rs@@ -5,3 +5,3 @@ use core::sync::atomic::{AtomicU64, Ordering};
#[cfg(not(target_has_atomic = "64"))]
-use crate::prelude::*;+use crate::sync::Mutex;
$ 

[tnull]

LGTM, happy to land it if CI passes.

[TheBlueMatt]

FFS

$ git diff-tree -U1 38ecd35c7 dccdd3c15
diff --git a/lightning/src/sign/mod.rs b/lightning/src/sign/mod.rs
index 41354c695..4b8a9e025 100644
--- a/lightning/src/sign/mod.rs+++ b/lightning/src/sign/mod.rs@@ -1029,3 +1029,2 @@ pub trait ChangeDestinationSource {
/// a secure external signer.
-#[derive(Debug)]
pub struct InMemorySigner {
@@ -2483,3 +2482,2 @@ impl PhantomKeysManager {
/// An implementation of [`EntropySource`] using ChaCha20.
-#[derive(Debug)]
pub struct RandomBytes {
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index 6dbe54e64..3627ccf8a 100644
--- a/lightning/src/util/atomic_counter.rs+++ b/lightning/src/util/atomic_counter.rs@@ -7,3 +7,2 @@ use crate::sync::Mutex;
-#[derive(Debug)]
pub(crate) struct AtomicCounter {
$ 

[tnull]

FFS

Nope:

error[E0596]: cannot borrow `mtx` as mutable, as it is not declared as mutable
--> /home/runner/work/rust-lightning/rust-lightning/lightning/src/util/atomic_counter.rs:30:5
|
30 | *mtx += 1;
| ^^^ cannot borrow as mutable
|
help: consider changing this to be mutable
|
29 | let mut mtx = self.counter.lock().unwrap();
| +++
For more information about this error, try `rustc --explain E0596`.
warning: `lightning` (lib) generated 1 warning
error: could not compile `lightning` (lib) due to 1 previous error; 1 warning emitted
Error: Process completed with exit code 101.

[TheBlueMatt]

Grr, guess I didn't have the arm compiler installed so running CI locally didn't test it...

$ git diff-tree -U2 dccdd3c15 68d4c9673
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index 3627ccf8a..b1fd7323f 100644
--- a/lightning/src/util/atomic_counter.rs
+++ b/lightning/src/util/atomic_counter.rs
@@ -38,5 +38,5 @@ impl AtomicCounter {
}
#[cfg(not(target_has_atomic = "64"))] {
- let mtx = self.counter.lock().unwrap();
+ let mut mtx = self.counter.lock().unwrap();
*mtx = count;
}
$ 

[tnull]

LGTM, landing this as pretty trivial.

[Kixunil]

If the intention is to produce some unique values that maybe don't need to be sequential you can still have a sensible lock-free implementation. Roughly like this:

letmut low = self.low.load(Relaxed);letmut high = self.high.load(Relaxed);loop{let new_low = if low == u32::MAX{// don't use fetch_add to avoid incrementing high by more than 1ifletErr(new) = self.high.compare_exchange(high, high + 1,Relaxed,Relaxed){
high = new;}0}else{
low + 1}// FTR this cannot be weakmatchself.low.compare_exchange(low, new_low,Relaxed,Relaxed){Ok(_) => break,Err(new) => low = new,}}
u64::from(high) << 32 | u64::from(low)

This assumes that a thread doesn't get scheduled-out after incrementing high for so long that other thread(s) manage to increment the counter by 2^32, which I think is a reasonable assumption. There's still a chance that high gets bumped by more than one though if a thread managed to bump it and before it updates low another thread reads both of them. This is quite unfrequent and could be dealt with by sacrificing one bit of high which gets set first and then reset at the end.

[Kixunil]

You have AcqRel however to my understanding this is not a synchronization primitive so Relaxed is appropriate.

[TheBlueMatt]

AtomicCounter was slightly race-y on 32-bit platforms because it
increments the high AtomicUsize independently from the low
AtomicUsize, leading to a potential race where another thread
could observe the low increment but not the high increment and see
a value of 0 twice.

This isn't a big deal because (a) most platforms are 64-bit these
days, (b) 32-bit platforms aren't super likely to have their
counter overflow 32 bits anyway, and (c) the two writes are
back-to-back so having another thread read during that window is
very unlikely.

However, we can also optimize the counter somewhat by using the
target_has_atomic = "64" cfg flag, which we do here, allowing us
to use AtomicU64 even on 32-bit platforms where 64-bit atomics
are available.

This changes some test behavior slightly, which requires
adaptation.

Fixes#3000

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.57%. Comparing base (d35239c) to head (1c2bd09).
Report is 33 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3302 +/- ##
==========================================
+ Coverage 89.85% 90.57% +0.72% 
==========================================
Files 126 126 Lines 104145 109040 +4895 Branches 104145 109040 +4895 ==========================================
+ Hits 93577 98761 +5184 + Misses 7894 7624 -270 + Partials 2674 2655 -19 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tnull]

nit: Preexisting, this naming seems a bit confusing as we're actually not returning the incremented counter. Maybe the field should be called next_counter and the method just next()?

[tnull]

LGTM, I think. Feel free to squash the fixup.

[TheBlueMatt]

Squashed.

[tnull]

Squashed.

It seems you're missing some imports here, CI is sad:

error[E0412]: cannot find type `Mutex` in this scope
--> /home/runner/work/rust-lightning/rust-lightning/lightning/src/util/atomic_counter.rs:13:11
|
13 | counter: Mutex<u64>,
| ^^^^^ not found in this scope
|
help: consider importing this struct through its public re-export
|
5 + use crate::sync::Mutex;
|

etc

[TheBlueMatt]

Gah

$ git diff-tree -U1 7b1f07bd3 38ecd35c7
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index d00c7341b..6dbe54e64 100644
--- a/lightning/src/util/atomic_counter.rs+++ b/lightning/src/util/atomic_counter.rs@@ -5,3 +5,3 @@ use core::sync::atomic::{AtomicU64, Ordering};
#[cfg(not(target_has_atomic = "64"))]
-use crate::prelude::*;+use crate::sync::Mutex;
$ 

[tnull]

LGTM, happy to land it if CI passes.

[TheBlueMatt]

FFS

$ git diff-tree -U1 38ecd35c7 dccdd3c15
diff --git a/lightning/src/sign/mod.rs b/lightning/src/sign/mod.rs
index 41354c695..4b8a9e025 100644
--- a/lightning/src/sign/mod.rs+++ b/lightning/src/sign/mod.rs@@ -1029,3 +1029,2 @@ pub trait ChangeDestinationSource {
/// a secure external signer.
-#[derive(Debug)]
pub struct InMemorySigner {
@@ -2483,3 +2482,2 @@ impl PhantomKeysManager {
/// An implementation of [`EntropySource`] using ChaCha20.
-#[derive(Debug)]
pub struct RandomBytes {
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index 6dbe54e64..3627ccf8a 100644
--- a/lightning/src/util/atomic_counter.rs+++ b/lightning/src/util/atomic_counter.rs@@ -7,3 +7,2 @@ use crate::sync::Mutex;
-#[derive(Debug)]
pub(crate) struct AtomicCounter {
$ 

[tnull]

FFS

Nope:

error[E0596]: cannot borrow `mtx` as mutable, as it is not declared as mutable
--> /home/runner/work/rust-lightning/rust-lightning/lightning/src/util/atomic_counter.rs:30:5
|
30 | *mtx += 1;
| ^^^ cannot borrow as mutable
|
help: consider changing this to be mutable
|
29 | let mut mtx = self.counter.lock().unwrap();
| +++
For more information about this error, try `rustc --explain E0596`.
warning: `lightning` (lib) generated 1 warning
error: could not compile `lightning` (lib) due to 1 previous error; 1 warning emitted
Error: Process completed with exit code 101.

[TheBlueMatt]

Grr, guess I didn't have the arm compiler installed so running CI locally didn't test it...

$ git diff-tree -U2 dccdd3c15 68d4c9673
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index 3627ccf8a..b1fd7323f 100644
--- a/lightning/src/util/atomic_counter.rs
+++ b/lightning/src/util/atomic_counter.rs
@@ -38,5 +38,5 @@ impl AtomicCounter {
}
#[cfg(not(target_has_atomic = "64"))] {
- let mtx = self.counter.lock().unwrap();
+ let mut mtx = self.counter.lock().unwrap();
*mtx = count;
}
$ 

[tnull]

LGTM, landing this as pretty trivial.

[Kixunil]

If the intention is to produce some unique values that maybe don't need to be sequential you can still have a sensible lock-free implementation. Roughly like this:

letmut low = self.low.load(Relaxed);letmut high = self.high.load(Relaxed);loop{let new_low = if low == u32::MAX{// don't use fetch_add to avoid incrementing high by more than 1ifletErr(new) = self.high.compare_exchange(high, high + 1,Relaxed,Relaxed){
high = new;}0}else{
low + 1}// FTR this cannot be weakmatchself.low.compare_exchange(low, new_low,Relaxed,Relaxed){Ok(_) => break,Err(new) => low = new,}}
u64::from(high) << 32 | u64::from(low)

This assumes that a thread doesn't get scheduled-out after incrementing high for so long that other thread(s) manage to increment the counter by 2^32, which I think is a reasonable assumption. There's still a chance that high gets bumped by more than one though if a thread managed to bump it and before it updates low another thread reads both of them. This is quite unfrequent and could be dealt with by sacrificing one bit of high which gets set first and then reset at the end.

[Kixunil]

You have AcqRel however to my understanding this is not a synchronization primitive so Relaxed is appropriate.

[TheBlueMatt]

AtomicCounter was slightly race-y on 32-bit platforms because it
increments the high AtomicUsize independently from the low
AtomicUsize, leading to a potential race where another thread
could observe the low increment but not the high increment and see
a value of 0 twice.

This isn't a big deal because (a) most platforms are 64-bit these
days, (b) 32-bit platforms aren't super likely to have their
counter overflow 32 bits anyway, and (c) the two writes are
back-to-back so having another thread read during that window is
very unlikely.

However, we can also optimize the counter somewhat by using the
target_has_atomic = "64" cfg flag, which we do here, allowing us
to use AtomicU64 even on 32-bit platforms where 64-bit atomics
are available.

This changes some test behavior slightly, which requires
adaptation.

Fixes#3000

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.57%. Comparing base (d35239c) to head (1c2bd09).
Report is 33 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3302 +/- ##
==========================================
+ Coverage 89.85% 90.57% +0.72% 
==========================================
Files 126 126 Lines 104145 109040 +4895 Branches 104145 109040 +4895 ==========================================
+ Hits 93577 98761 +5184 + Misses 7894 7624 -270 + Partials 2674 2655 -19 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tnull]

nit: Preexisting, this naming seems a bit confusing as we're actually not returning the incremented counter. Maybe the field should be called next_counter and the method just next()?

[tnull]

LGTM, I think. Feel free to squash the fixup.

[TheBlueMatt]

Squashed.

[tnull]

Squashed.

It seems you're missing some imports here, CI is sad:

error[E0412]: cannot find type `Mutex` in this scope
--> /home/runner/work/rust-lightning/rust-lightning/lightning/src/util/atomic_counter.rs:13:11
|
13 | counter: Mutex<u64>,
| ^^^^^ not found in this scope
|
help: consider importing this struct through its public re-export
|
5 + use crate::sync::Mutex;
|

etc

[TheBlueMatt]

Gah

$ git diff-tree -U1 7b1f07bd3 38ecd35c7
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index d00c7341b..6dbe54e64 100644
--- a/lightning/src/util/atomic_counter.rs+++ b/lightning/src/util/atomic_counter.rs@@ -5,3 +5,3 @@ use core::sync::atomic::{AtomicU64, Ordering};
#[cfg(not(target_has_atomic = "64"))]
-use crate::prelude::*;+use crate::sync::Mutex;
$ 

[tnull]

LGTM, happy to land it if CI passes.

[TheBlueMatt]

FFS

$ git diff-tree -U1 38ecd35c7 dccdd3c15
diff --git a/lightning/src/sign/mod.rs b/lightning/src/sign/mod.rs
index 41354c695..4b8a9e025 100644
--- a/lightning/src/sign/mod.rs+++ b/lightning/src/sign/mod.rs@@ -1029,3 +1029,2 @@ pub trait ChangeDestinationSource {
/// a secure external signer.
-#[derive(Debug)]
pub struct InMemorySigner {
@@ -2483,3 +2482,2 @@ impl PhantomKeysManager {
/// An implementation of [`EntropySource`] using ChaCha20.
-#[derive(Debug)]
pub struct RandomBytes {
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index 6dbe54e64..3627ccf8a 100644
--- a/lightning/src/util/atomic_counter.rs+++ b/lightning/src/util/atomic_counter.rs@@ -7,3 +7,2 @@ use crate::sync::Mutex;
-#[derive(Debug)]
pub(crate) struct AtomicCounter {
$ 

[tnull]

FFS

Nope:

error[E0596]: cannot borrow `mtx` as mutable, as it is not declared as mutable
--> /home/runner/work/rust-lightning/rust-lightning/lightning/src/util/atomic_counter.rs:30:5
|
30 | *mtx += 1;
| ^^^ cannot borrow as mutable
|
help: consider changing this to be mutable
|
29 | let mut mtx = self.counter.lock().unwrap();
| +++
For more information about this error, try `rustc --explain E0596`.
warning: `lightning` (lib) generated 1 warning
error: could not compile `lightning` (lib) due to 1 previous error; 1 warning emitted
Error: Process completed with exit code 101.

[TheBlueMatt]

Grr, guess I didn't have the arm compiler installed so running CI locally didn't test it...

$ git diff-tree -U2 dccdd3c15 68d4c9673
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index 3627ccf8a..b1fd7323f 100644
--- a/lightning/src/util/atomic_counter.rs
+++ b/lightning/src/util/atomic_counter.rs
@@ -38,5 +38,5 @@ impl AtomicCounter {
}
#[cfg(not(target_has_atomic = "64"))] {
- let mtx = self.counter.lock().unwrap();
+ let mut mtx = self.counter.lock().unwrap();
*mtx = count;
}
$ 

[tnull]

LGTM, landing this as pretty trivial.

[Kixunil]

If the intention is to produce some unique values that maybe don't need to be sequential you can still have a sensible lock-free implementation. Roughly like this:

letmut low = self.low.load(Relaxed);letmut high = self.high.load(Relaxed);loop{let new_low = if low == u32::MAX{// don't use fetch_add to avoid incrementing high by more than 1ifletErr(new) = self.high.compare_exchange(high, high + 1,Relaxed,Relaxed){
high = new;}0}else{
low + 1}// FTR this cannot be weakmatchself.low.compare_exchange(low, new_low,Relaxed,Relaxed){Ok(_) => break,Err(new) => low = new,}}
u64::from(high) << 32 | u64::from(low)

This assumes that a thread doesn't get scheduled-out after incrementing high for so long that other thread(s) manage to increment the counter by 2^32, which I think is a reasonable assumption. There's still a chance that high gets bumped by more than one though if a thread managed to bump it and before it updates low another thread reads both of them. This is quite unfrequent and could be dealt with by sacrificing one bit of high which gets set first and then reset at the end.

[Kixunil]

You have AcqRel however to my understanding this is not a synchronization primitive so Relaxed is appropriate.

[TheBlueMatt]

AtomicCounter was slightly race-y on 32-bit platforms because it
increments the high AtomicUsize independently from the low
AtomicUsize, leading to a potential race where another thread
could observe the low increment but not the high increment and see
a value of 0 twice.

This isn't a big deal because (a) most platforms are 64-bit these
days, (b) 32-bit platforms aren't super likely to have their
counter overflow 32 bits anyway, and (c) the two writes are
back-to-back so having another thread read during that window is
very unlikely.

However, we can also optimize the counter somewhat by using the
target_has_atomic = "64" cfg flag, which we do here, allowing us
to use AtomicU64 even on 32-bit platforms where 64-bit atomics
are available.

This changes some test behavior slightly, which requires
adaptation.

Fixes#3000

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.57%. Comparing base (d35239c) to head (1c2bd09).
Report is 33 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3302 +/- ##
==========================================
+ Coverage 89.85% 90.57% +0.72% 
==========================================
Files 126 126 Lines 104145 109040 +4895 Branches 104145 109040 +4895 ==========================================
+ Hits 93577 98761 +5184 + Misses 7894 7624 -270 + Partials 2674 2655 -19 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tnull]

nit: Preexisting, this naming seems a bit confusing as we're actually not returning the incremented counter. Maybe the field should be called next_counter and the method just next()?

[tnull]

LGTM, I think. Feel free to squash the fixup.

[TheBlueMatt]

Squashed.

[tnull]

Squashed.

It seems you're missing some imports here, CI is sad:

error[E0412]: cannot find type `Mutex` in this scope
--> /home/runner/work/rust-lightning/rust-lightning/lightning/src/util/atomic_counter.rs:13:11
|
13 | counter: Mutex<u64>,
| ^^^^^ not found in this scope
|
help: consider importing this struct through its public re-export
|
5 + use crate::sync::Mutex;
|

etc

[TheBlueMatt]

Gah

$ git diff-tree -U1 7b1f07bd3 38ecd35c7
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index d00c7341b..6dbe54e64 100644
--- a/lightning/src/util/atomic_counter.rs+++ b/lightning/src/util/atomic_counter.rs@@ -5,3 +5,3 @@ use core::sync::atomic::{AtomicU64, Ordering};
#[cfg(not(target_has_atomic = "64"))]
-use crate::prelude::*;+use crate::sync::Mutex;
$ 

[tnull]

LGTM, happy to land it if CI passes.

[TheBlueMatt]

FFS

$ git diff-tree -U1 38ecd35c7 dccdd3c15
diff --git a/lightning/src/sign/mod.rs b/lightning/src/sign/mod.rs
index 41354c695..4b8a9e025 100644
--- a/lightning/src/sign/mod.rs+++ b/lightning/src/sign/mod.rs@@ -1029,3 +1029,2 @@ pub trait ChangeDestinationSource {
/// a secure external signer.
-#[derive(Debug)]
pub struct InMemorySigner {
@@ -2483,3 +2482,2 @@ impl PhantomKeysManager {
/// An implementation of [`EntropySource`] using ChaCha20.
-#[derive(Debug)]
pub struct RandomBytes {
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index 6dbe54e64..3627ccf8a 100644
--- a/lightning/src/util/atomic_counter.rs+++ b/lightning/src/util/atomic_counter.rs@@ -7,3 +7,2 @@ use crate::sync::Mutex;
-#[derive(Debug)]
pub(crate) struct AtomicCounter {
$ 

[tnull]

FFS

Nope:

error[E0596]: cannot borrow `mtx` as mutable, as it is not declared as mutable
--> /home/runner/work/rust-lightning/rust-lightning/lightning/src/util/atomic_counter.rs:30:5
|
30 | *mtx += 1;
| ^^^ cannot borrow as mutable
|
help: consider changing this to be mutable
|
29 | let mut mtx = self.counter.lock().unwrap();
| +++
For more information about this error, try `rustc --explain E0596`.
warning: `lightning` (lib) generated 1 warning
error: could not compile `lightning` (lib) due to 1 previous error; 1 warning emitted
Error: Process completed with exit code 101.

[TheBlueMatt]

Grr, guess I didn't have the arm compiler installed so running CI locally didn't test it...

$ git diff-tree -U2 dccdd3c15 68d4c9673
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index 3627ccf8a..b1fd7323f 100644
--- a/lightning/src/util/atomic_counter.rs
+++ b/lightning/src/util/atomic_counter.rs
@@ -38,5 +38,5 @@ impl AtomicCounter {
}
#[cfg(not(target_has_atomic = "64"))] {
- let mtx = self.counter.lock().unwrap();
+ let mut mtx = self.counter.lock().unwrap();
*mtx = count;
}
$ 

[tnull]

LGTM, landing this as pretty trivial.

[Kixunil]

If the intention is to produce some unique values that maybe don't need to be sequential you can still have a sensible lock-free implementation. Roughly like this:

letmut low = self.low.load(Relaxed);letmut high = self.high.load(Relaxed);loop{let new_low = if low == u32::MAX{// don't use fetch_add to avoid incrementing high by more than 1ifletErr(new) = self.high.compare_exchange(high, high + 1,Relaxed,Relaxed){
high = new;}0}else{
low + 1}// FTR this cannot be weakmatchself.low.compare_exchange(low, new_low,Relaxed,Relaxed){Ok(_) => break,Err(new) => low = new,}}
u64::from(high) << 32 | u64::from(low)

This assumes that a thread doesn't get scheduled-out after incrementing high for so long that other thread(s) manage to increment the counter by 2^32, which I think is a reasonable assumption. There's still a chance that high gets bumped by more than one though if a thread managed to bump it and before it updates low another thread reads both of them. This is quite unfrequent and could be dealt with by sacrificing one bit of high which gets set first and then reset at the end.

[Kixunil]

You have AcqRel however to my understanding this is not a synchronization primitive so Relaxed is appropriate.

[TheBlueMatt]

AtomicCounter was slightly race-y on 32-bit platforms because it
increments the high AtomicUsize independently from the low
AtomicUsize, leading to a potential race where another thread
could observe the low increment but not the high increment and see
a value of 0 twice.

This isn't a big deal because (a) most platforms are 64-bit these
days, (b) 32-bit platforms aren't super likely to have their
counter overflow 32 bits anyway, and (c) the two writes are
back-to-back so having another thread read during that window is
very unlikely.

However, we can also optimize the counter somewhat by using the
target_has_atomic = "64" cfg flag, which we do here, allowing us
to use AtomicU64 even on 32-bit platforms where 64-bit atomics
are available.

This changes some test behavior slightly, which requires
adaptation.

Fixes#3000

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.57%. Comparing base (d35239c) to head (1c2bd09).
Report is 33 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3302 +/- ##
==========================================
+ Coverage 89.85% 90.57% +0.72% 
==========================================
Files 126 126 Lines 104145 109040 +4895 Branches 104145 109040 +4895 ==========================================
+ Hits 93577 98761 +5184 + Misses 7894 7624 -270 + Partials 2674 2655 -19 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tnull]

nit: Preexisting, this naming seems a bit confusing as we're actually not returning the incremented counter. Maybe the field should be called next_counter and the method just next()?

[tnull]

LGTM, I think. Feel free to squash the fixup.

[TheBlueMatt]

Squashed.

[tnull]

Squashed.

It seems you're missing some imports here, CI is sad:

error[E0412]: cannot find type `Mutex` in this scope
--> /home/runner/work/rust-lightning/rust-lightning/lightning/src/util/atomic_counter.rs:13:11
|
13 | counter: Mutex<u64>,
| ^^^^^ not found in this scope
|
help: consider importing this struct through its public re-export
|
5 + use crate::sync::Mutex;
|

etc

[TheBlueMatt]

Gah

$ git diff-tree -U1 7b1f07bd3 38ecd35c7
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index d00c7341b..6dbe54e64 100644
--- a/lightning/src/util/atomic_counter.rs+++ b/lightning/src/util/atomic_counter.rs@@ -5,3 +5,3 @@ use core::sync::atomic::{AtomicU64, Ordering};
#[cfg(not(target_has_atomic = "64"))]
-use crate::prelude::*;+use crate::sync::Mutex;
$ 

[tnull]

LGTM, happy to land it if CI passes.

[TheBlueMatt]

FFS

$ git diff-tree -U1 38ecd35c7 dccdd3c15
diff --git a/lightning/src/sign/mod.rs b/lightning/src/sign/mod.rs
index 41354c695..4b8a9e025 100644
--- a/lightning/src/sign/mod.rs+++ b/lightning/src/sign/mod.rs@@ -1029,3 +1029,2 @@ pub trait ChangeDestinationSource {
/// a secure external signer.
-#[derive(Debug)]
pub struct InMemorySigner {
@@ -2483,3 +2482,2 @@ impl PhantomKeysManager {
/// An implementation of [`EntropySource`] using ChaCha20.
-#[derive(Debug)]
pub struct RandomBytes {
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index 6dbe54e64..3627ccf8a 100644
--- a/lightning/src/util/atomic_counter.rs+++ b/lightning/src/util/atomic_counter.rs@@ -7,3 +7,2 @@ use crate::sync::Mutex;
-#[derive(Debug)]
pub(crate) struct AtomicCounter {
$ 

[tnull]

FFS

Nope:

error[E0596]: cannot borrow `mtx` as mutable, as it is not declared as mutable
--> /home/runner/work/rust-lightning/rust-lightning/lightning/src/util/atomic_counter.rs:30:5
|
30 | *mtx += 1;
| ^^^ cannot borrow as mutable
|
help: consider changing this to be mutable
|
29 | let mut mtx = self.counter.lock().unwrap();
| +++
For more information about this error, try `rustc --explain E0596`.
warning: `lightning` (lib) generated 1 warning
error: could not compile `lightning` (lib) due to 1 previous error; 1 warning emitted
Error: Process completed with exit code 101.

[TheBlueMatt]

Grr, guess I didn't have the arm compiler installed so running CI locally didn't test it...

$ git diff-tree -U2 dccdd3c15 68d4c9673
diff --git a/lightning/src/util/atomic_counter.rs b/lightning/src/util/atomic_counter.rs
index 3627ccf8a..b1fd7323f 100644
--- a/lightning/src/util/atomic_counter.rs
+++ b/lightning/src/util/atomic_counter.rs
@@ -38,5 +38,5 @@ impl AtomicCounter {
}
#[cfg(not(target_has_atomic = "64"))] {
- let mtx = self.counter.lock().unwrap();
+ let mut mtx = self.counter.lock().unwrap();
*mtx = count;
}
$ 

[tnull]

LGTM, landing this as pretty trivial.

[Kixunil]

If the intention is to produce some unique values that maybe don't need to be sequential you can still have a sensible lock-free implementation. Roughly like this:

letmut low = self.low.load(Relaxed);letmut high = self.high.load(Relaxed);loop{let new_low = if low == u32::MAX{// don't use fetch_add to avoid incrementing high by more than 1ifletErr(new) = self.high.compare_exchange(high, high + 1,Relaxed,Relaxed){
high = new;}0}else{
low + 1}// FTR this cannot be weakmatchself.low.compare_exchange(low, new_low,Relaxed,Relaxed){Ok(_) => break,Err(new) => low = new,}}
u64::from(high) << 32 | u64::from(low)

This assumes that a thread doesn't get scheduled-out after incrementing high for so long that other thread(s) manage to increment the counter by 2^32, which I think is a reasonable assumption. There's still a chance that high gets bumped by more than one though if a thread managed to bump it and before it updates low another thread reads both of them. This is quite unfrequent and could be dealt with by sacrificing one bit of high which gets set first and then reset at the end.

[Kixunil]

You have AcqRel however to my understanding this is not a synchronization primitive so Relaxed is appropriate.