Strange race condition on Windows

> Detecting the CPU architecture Just searched for this topic. And it seems to be a little more complicated when Rosetta is involved. For example, [this person](https://developer.apple.com/forums/thread/659846) said `uname -m` will return `x86_64` when Rosetta is used, even on an `arm64` comput

Strange race condition on Windows

But I think you should instead use `brew` to install the Nim compiler, if possible.

Strange race condition on Windows

> When not specifying any options, we want archB to equal archC Adding switch("cpu", "arm64") Run to the top of your default `config.nims` may solve this problem. The compiler will then generate the correct C code for your C compiler.

Strange race condition on Windows

Mac and BSD are very close :-)

Strange race condition on Windows

> Maybe the best solution is to fix choosenim so that it compiles to the proper > target on Mac? I think that sounds like a reasonable strategy. There's a logistical difficulty in that the creator/maintainer of choosenim is no longer involved in the Nim community and has been unresponsive since

Strange race condition on Windows

> I know it's just koch boot -d:release You may also have to specify `--cpu:arm64` to prevent generating another x86-64 compiler. You need to cross-compile for macOS/AArch64, not compile "on" it. > detecting the CPU architecture Is it possible on Rosetta? > at least providing an ARM version A

Strange race condition on Windows

If you install Nim using Homebrew, you'll get version 2.0.2 compiled for Arm.

Strange race condition on Windows

I will, but it really feels wrong... This is Mac, not Nix / Arch. Non technical users trying out Nim should not be expected to compile their compiler. I know it's just `koch boot -d:release`, but like for a first time user (maybe coming from python), this is daunting. I really like the idea of d

Strange race condition on Windows

> I know that compiling Nim from scratch on Mac would solve the issue, but this > is a weird way to do it. This is what you should really do. ;-)

Strange race condition on Windows

Thank you for this reply! I might also write a PR to add this code as a test if I manage to increase the probability of crashes enough.

Strange race condition on Windows

It is a Mac M1. I'm using clang as the compiler. When calling `cpuRelax` in an empty file, I'm getting: error: unrecognized instruction mnemonic asm volatile("pause" ::: "memory")"; This is because `amd64` is defined. The nim compiler I use was compiled on an intel CPU. I use rosetta to run it.

Strange race condition on Windows

> malebogia does not support MacOS because cpuRelax() uses some assembly that > does not exist on ARM What? I developed malebolgia on a Mac and it does work... What is your setup?

Strange race condition on Windows

> Even this example, without any ref, does not work: ... This example is supposed to work and does when you disable Nim's broken default allocator. That is a regression with the 2.0 line. You really need `-d:useMalloc` for the time being, sorry. I've "fixed" this bug months ago but it causes ot

Strange race condition on Windows

In the code example at [the thread @brainproxy mentioned](https://forum.nim-lang.org/t/11203) are some problems that make it unsafe, including: * In the thread, a _variable_ of a `ref` type is created and assigned to, which increases the reference count by one. As "increasing the reference co

Strange race condition on Windows

Using `-d:useMalloc` fixes this, but once again, why? What is the default memory allocator for Nim if not malloc? When looking at the source code, I cannot find the difference between `allocShared` and `alloc`, is there one? There is so much documentation missing and even browsing at the source

Strange race condition on Windows

The example with the global string `s` still crashes with `--mm:atomicArc`. But even without it, if a modification of an integer (like a reference count) is only done when a mutex is locked, it should make it atomic? Or the destuctors are called outside the lock sections?

Strange race condition on Windows

If there was no lock, this explanation would make sense, but in my code, the variable access happens behind a lock, so why would there be non-atomic writes

Strange race condition on Windows

There being a lock in place does not impact/resolve the problem of Nim’s reference counting not being atomic (unless using `--mm:atomicArc`).

Strange race condition on Windows

The more I try things, the more I'm confused. Even this example, without any ref, does not work: import locks import os var s: string var c: int var l: Lock proc myFunc() {.thread.} = for i in 0..<50: os.sleep(1) {.gcsafe.

Strange race condition on Windows

The reference counting for ARC/ORC is not atomic and therefore problematic for multiple threads. See this similar discussion and note there is an experimental `--mm:atomicArc`:

Strange race condition on Windows

Moreover, using `Lockers` without `spawn` does not work: import malebolgia / lockers type Example = object s: string c: int proc threadFunc(lockedObj: Locker[Example]) {.thread.} = lock lockedObj as obj: obj.s.add($obj.c)

Strange race condition on Windows

I was interested in implementing a library like malbolgia myself, I'll look at the source code, the locker implementation is what I need. The following works: import malebolgia import malebolgia / lockers type Example = object s: string c: int p

Strange race condition on Windows

Mastering Nim has a malbolgia example that does what you're attempting here with [lockers](https://github.com/Araq/malebolgia?tab=readme-ov-file#lockers), and has this warning: > A `ref T` pointer is implemented with reference counting and based on the > lifetime-tracking hooks. For performance

Strange race condition on Windows

How can I share memory between threads? Do I have to use pointers with allocShared and manual memory manager? Do pointer with alloc work ? Is there documentation somewhere about this?

Strange race condition on Windows

`Thread[Example]` is not supported since you use a `ref`.

Strange race condition on Windows

By adding an `echo` inside `threadFunc`, I can get it to crash every time: proc threadFunc(obj: Example) {.thread.} = withLock lock: echo "Inside thread" obj.s.add($obj.c) inc obj.c Run Once again, this only occurs on windows.

Strange race condition on Windows

I wanted to add more examples to as I feel that some modules lack documentation. I wrote a small program to show how to share memory between threads in Nim: import locks type Example = ref object s: string c: int