JoeJ said:

I'm guess it is as simple as you thought, but first you need to figure out how to tell the computer to do what you want.

Yeah there are a few things annoying. You can't use a thread like an object you can't use in a switch statement you have to put it into a function first. etc.

taby said:

If you’re looking for an example code, please check out

https://github.com/sjhalayka/tcpspeed3_multithreaded_listener

taby I had a look once again at the code that you posted at the beginning of the discussion. I'm not familiar with passing arguments to a function like that, but that's probably just passing arguments by reference. I understand the example now more or less, I think I found my thread ended flag )

Calin said:
Yeah there are a few things annoying. You can't use a thread like an object you can't use in a switch statement you have to put it into a function first. etc.

Yeah, but those things are not really a problem or can be worked around.

The most annoying thing to me is that atomic data types can't be copied. So you can't put atomic data into your general data structures.
Idk why this is. Maybe CPUs need to create atomic data types in some special memory region, or it's a legacy limitation.
On GPU this is much simpler: Any data can be accessed with atomic instructions. I wish it would be the same on CPU, but seemingly this isn't possible.

Calin said:
I'm not familiar with passing arguments to a function like that, but that's probably just passing arguments by reference.

Iirc, std::ref is needed because the thread constructor would otherwise only make a local copy even if it's given as reference.
Quirky, but as said: Most of those complications rise from the C++ language and it's newer features to make MT easier to use, but then requiring some more knowledge about the language. There always is a lower level way of doing things, not requiring this knowledge, e.g. by using pointers instead references in this case.

C++ doesn't know about the underlying hardware so it leaves a lot to implementation defined behavior. It also includes some features to add barriers if the hardware might need it, like atomic wrappers. The same c++ code could be compiled for an 8-bit AVR processor, a 32-bit cortex, or a 64-bit x86-64 machine.

Moving data larger than the processing size isn't atomic, moving a 32-bit value on an 8-bit processor can take four steps, meaning another thread can read a partiality written value. The same with 64-bit values on any system using less than 64-bit instructions. The same is also true for cpu cache lines, if variables are larger than a cache entry or spans across cache lines.

If you are only on modern big processors the basic types of integral and float types are all atomic both on a processor and across cpus. You are likely working on 64-bit cpus with similarly sized or multiple-size cache lines, so the hardware does them atomically. That's not true if you are compiling for other hardware.

frob said:
Eventually your main thread needs to release the thread resources either by joining back up or detaching the thread.

Now that I understand taby's example I understand this too.

Optimization is something I'm not good with at all (I can't write slim algorithms for my game or the better AI ideas that I have) hence I'm looking for cheap computing power.

JoeJ said:

Yeah, but those

(I'm not going to quote the bit that makes my interest, I would be easily reverse engineered if I did ))) you know what I'm talking about)

I get what you're saying

frob said:
You are likely working on 64-bit cpus with similarly sized or multiple-size cache lines, so the hardware does them atomically.

But how far does that go?
Writing and reading is atomic, but i guess atomic add, max or exchange is not, because that's eventually two or more instructions for those basic operations?

It depends, and different chips provide different operations. That's why much of it remains either implementation defined or system specific.

There are plenty of systems that have conditional instructions and atomic “test and set” and also lock/unlock instructions to do the work, and also plenty of systems that don't. The x86 family has quite a few of them, but the same c++ code could work on feature phones, on microcontrollers, and on other systems that don't include the hardware.

The c++ standard is doing more to expose the functionality when present in the hardware while providing software functionality when it isn't. That's not a new thing, floating point is another that is emulated on some hardware even though it is very common. Before about 1994 floating point hardware was quite rare on PCs but the language supported it through software libraries. Bit-shift is another some hardware doesn't support. The same with 32-bit and 64-bit types even in hardware that doesn't directly support it, the compiler libraries do the extra work behind your back.