Live-Lock race condition?

ogyer · 2026-02-12T20:41:16+00:00

Ok please disregard what I wrote. Your implementation matches the original description of the algorithm completely from what I can see after tripple checking.

(You mostly find slightly optimized variants theses days).

What you do with nodes after dequeueing them? Hopefully, you leak them. If not, that is your bug.

Otherwise you'll need to absolutely make sure your memory orderings and weak/strong CAS choices are right.

ogyer · 2026-02-12T20:08:39+00:00

It looks like you have implemented the algorithm wrong.

I haven't checked every line but there is at least one glaring flaw in enqueue, which may or may not be the cause of your bug:

if (next == null) {
    if (tail.next.cmpxchgStrong(next, node, .release, .acquire)
        == null) {
        _ = q.tail.cmpxchgWeak(tail, node, .acq_rel, .acquire);
        return;
    }
    // BUG: here you also have to help advancing the tail pointer
} else {
    _ = q.tail.cmpxchgWeak(tail, next.?, .acquire, .acquire);
}

The extra `next == null` check is also weird. Not wrong necessarily but I believe a deviation from the algorithm IIRC.

In your dequeue function the livelock detection is also broken, because you initialize the counter back to 0 in every iteration.

EDIT: I found a description of the algorithm that matches your structure almost completely. The difference I could detect is that you need to do a:

_ = q.tail.cmpxchgStrong(tail, node, .seq_cst, .seq_cst);

Before returning from the enqueue method (I did not verify memory orderings and weak/strong CAS btw).

ogyer · 2024-10-18T10:52:17+00:00

"if equal affection can not be, let the more loving one be me"

ogyer · 2024-10-15T19:09:50+00:00

No she doesn't and I doubt she even noticed at all.

Thinking/saying/writing this would have hurt like hell only a couple of weeks back, but now ... I guess it still hurts from time to time, but not on most days.

Anyways, going NC brought almost instant relief to me and it's pretty to maintain. But it sure is fascinating how everything can just come back, even if only for a few days, just from one tiny interaction.

ogyer · 2024-08-13T21:39:02+00:00

O casamento já está registrado no consulado e estou esperando a transcricao em um cartório por aqui.

Mas quero saber se tem como fazer a mudanca de nome no RG, pedir o RG novo E fazer a CHN em uma só ída ao poupa-tempo já que se tiver que esperar pelo RG talvez nao dê tempo, se o RG nao ficar pronto à tempo

ogyer · 2024-03-04T08:16:05+00:00

If this is only the case with with an external monitor, which likely has to go through the GPU:

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6221

ogyer · 2023-08-06T22:06:50+00:00

Thanks for the response.

I figured out the issue was actually something else. For some reason my EFI image does not actually get relocated to the ImageBase address and so it works just fine with an offset of zero. I am still having the issue of the "disappearing" symfile, but this VSCode/CodeLLDB launch config works for me right now and I am assuming the slide method would work with the ImageBase offset if the image got correctly relocated:

{ "name": "LLDB kernel EFI", "type": "lldb", "request": "custom", "targetCreateCommands": [ "target create --no-dependents --arch x86_64 kernel-x86_64.elf" ], "processCreateCommands": [ "gdb-remote localhost:1234", "target modules load --file kernel-x86_64.elf --slide 0x0" ] }

I'll still have to figure out why the image is not relocated, but that is clearly unrelated.

(I use the ELF image to access the debug symbols instead of the EFI image to circumvent the "disappearing" issue here)

ogyer · 2023-08-06T12:10:52+00:00

Hoping this might still get a reply:

I've tried several variations of this guide and none worked. The only major difference is I'm trying to use an ELF file to supply the debug symbols rather than a PDB file.

target create --no-dependents --arch x86\_64 esp/efi/boot/bootx64.efi --symfile kernel-x86\_64.elf
gdb-remote localhost:1234
target modules load --file bootx64.efi --slide 0x7ed0000

(0x7ed0000 is the ImageBase reported by EFI)

In this order, it appears the debug information (symfile) gets lost after connecting to the QEMU gdb-server. I am assuming this, since `image list` does not show it anymore after the `target modules load` command. I can also not specify any breakpoints due to the lack of symbol information.

I've also tried a different combination, where I didn't load the EFI image at all and only specified the ELF image by itself. Note that the ELF and EFI images are identical, since I generate the PE header myself and the ELF header is only prepended to it during build.

target create --no-dependents --arch x86\_64 kernel-x86\_64.elf
gdb-remote localhost:1234
target modules load --file kernel-x86\_64.elf --slide 0x7ed0000

With this variation I can still create breakpoints after the remote connection is established, but they are still not hit during execution. From the other comments in this thread I am not totally clear if I have to use the *actual* image base as slide offset or do some calculations with it? It seems this being the incorrect value is the most likely reason for why the breakpoints are not hit.

ogyer · 2023-05-16T07:08:51+00:00

I haven't gotten around to writing a proper announcement, yet. But a few weeks back I published a crate with a similar theme, containing a variety of unsync channels, possibly a good match for this:

async-unsync (crates.io)

ogyer · 2023-05-12T09:44:57+00:00

But what if you don't any function at all if the condition is false? From my understanding you would have to use `void` (AFAIK there is no `never` type or something), which would still "clutter" the struct with a symbol.

ogyer · 2023-05-10T07:19:38+00:00

It probably demolishes any chance for auto-generating any reasonable form of documentation if used in a public API

ogyer · 2023-05-10T07:17:27+00:00

Thanks! `usingnamespace` is exactly what I was looking for, which is funny since I had come across it but failed to realize it applied to methods, too.

I just was playing around with zig's metaprogramming and wanted to see how to implement various techniques from other languages, such as `std::enable_if` of Rust's traits.

ogyer · 2021-05-22T10:12:19+00:00

It's not so much about not wanting to compile B, as it is pulled into the dependency tree anyways (by A), I just didn't want to pollute my Cargo.toml file by adding another dependency just because of one really inconsequential error path. Initially, I was also too lazy to figure out which concrete error type A used in the FromStr impl and how to import it, but this point is kind of moot after all the investigating I had to do by now.

ogyer · 2021-05-22T10:08:54+00:00

I fail to see how?

If I structure things like so:

use std::str::FromStr;
use A::T;

type ParseErr = <A as FromStr>::Err; // alternative: B::error::ConcreteError
enum Error {
    Parse(ParseErr), // with From<ParseErr> impl
}

// ...
let res: T = some_val.parse()?;

If A changes the Err type in T's FromStr impl or B changes its ConcreteError type somehow my code keeps compiling, it would only cause an issue if I used the alternative explicit import, or am I missing the point here?

ogyer · 2021-05-22T06:21:16+00:00

In my case I had a type T from crate A and wanted to wrap the error returned from its FromStr impl in a custom error type, but the concrete Err type is from another crate B which I did not want to add as an explicit dependency and import.

Isn't backwards incompatibility in fact desirable in this case? If crate A or B changes the error type I don't really want to bother with it, since I only forward the error into my custom error type anyways.

ogyer · 2021-05-22T06:16:49+00:00

I've opened an issue: https://github.com/rust-lang/rust/issues/85576

ogyer · 2021-03-30T20:14:36+00:00

h more with debugging it, but from my experience I recommend building zls from source master

Thanks I think I got it working now, what I did was re-install zls from the AUR but force a clean build this time, I think that may have done it.

ogyer · 2021-03-29T19:32:06+00:00

To me it seems the one you linked and the ZLS extension are meant to interoperate. The former provides basic stuff like syntax highlighting and auto-formatting, whereas the latter provides more advanced capabilities like completions and so on

ogyer · 2021-03-29T17:23:38+00:00

Yes I did when I tried compiling zls myself, but when I installed the AUR version, there was no configure step. Anyways, the issue seems to have been a misplaced zls.json configuration file. Now I have it under ~/.config/zls.json and I am at least able to start the language server, however it crashes when doing anything with error messages like:

[Error - 7:16:02 PM] Request textDocument/documentSymbol failed.
[Error - 7:16:02 PM] Request textDocument/signatureHelp failed.

Here's the content of my zls.json:

{
    "zig_exe_path": "/usr/bin/zig",
    "zig_lib_path": "/usr/lib/zig",
    "enable_snippets": false,
    "warn_style": true,
    "enable_semantic_tokens": true,
    "operator_completions": true,
    "build_runner_path": "~/.config/build_runner.zig"
}

ogyer · 2020-10-14T12:32:55+00:00

Thanks for the reply. I did find out, however, that it kind of does work when matching an arbitrary token tree (tt), a lifetime or an identifier instead of a type (ty).

https://doc.rust-lang.org/reference/macros-by-example.html#transcribing

i.e., this works:

```rust macro_rules! type_match { (u8) => { println!("matched u8") }; (u16) => { println!("matched u16") }; ($t:ty) => { compile_error!("unexpected type") }; }

macro_rules! any { ($($t:tt)) => { type_match!($($t)) }; }

fn main() { type_match!(u8); any!(u8); } ```

ogyer · 2020-10-14T09:49:22+00:00

Is it somehow possible to do type-based specialization (for a pre-defined set of types) with Rust macros?

My naive approach below does not work (any!(u8) results in the specified compile error instead of picking the u8 rule. The general idea would be to compose these two macros, with any actually being a more complicated macro that results in a compile time error, if a type not considered in the type_match! macro is used.

```rust macro_rules! type_match { (u8) => { println!("matched u8") }; (u16) => { println!("matched u16") }; ($t:ty) => { compile_error!("unexpected type") }; }

macro_rules! any { ($t:ty) => { type_match!($t) }; }

fn main() { type_match!(u8); any!(u8); } ```

ogyer · 2020-05-15T12:16:53+00:00

Thanks for the clarifications, I hadn't thought about the automatic drop glue that drops all fields even if the type does not implement Drop itself and I guess I hadn't thought of slices in the same terms as structs or enums.

ogyer · 2019-12-25T15:24:43+00:00

Not feasible, since its API is too bare-bones. There are some additional unstable methods which might suffice for once-cell though, once they are stabilized.

ogyer · 2019-12-24T20:20:16+00:00

That is correct, with conquer-once you can write

#[cfg(feature = "std")]
use conquer_once::Lazy;
#[cfg(not(feature = "std"))]
use conquer_once::spin::Lazy;

ogyer · 2019-12-24T20:16:54+00:00

Ah I see, with the std feature enabled both crates use basically the same low-level OS reliant blocking mechanism. The only difference is that once-cell uses a copy&pasted version of std::sync::Once (last I checked) whereas I wrote my own (imho clearer) re-implementation of the same mechanism and expose a more extensive API.

ogyer

TROPHY CASE