core.stdc.stdatomic
claptrap
clap at trap.com
Wed Nov 15 13:48:36 UTC 2023
On Wednesday, 15 November 2023 at 10:26:32 UTC, Richard (Rikki)
Andrew Cattermole wrote:
> On 15/11/2023 10:55 PM, claptrap wrote:
> I understand that it seems like it does not make sense.
> Lock-free concurrent data structures are a highly advanced
> topic, that very few people in the world today can implement
> successfully. About the only people who are qualified to touch
> them for production software would be kernel developers for a
> specific cpu family.
Im saying it doesnt make sense because i have worked on /
implemented some lock free data structures. Ive shipped software
that relied on them.
None of the literature ive read ever had any algorithms that
relied on "getting things done quickly" after a CAS.
Fundamentally it cant work since the thread can be interupted
immediatly after completing the CAS. So if you algorithm relies
on something else happening within a specific time frame after a
CAS it is not going to work.
So im looking for an explanation or a pointer to an algorithm
that exhibits what you describe because it is counter to my
experience.
> They rely quite heavily on the premise that atomic operations
> happen immediately in the codegen and then based upon the
> results do set actions in response. This is timing based it has
> to be preciese or they will interfere with each other. You do
> not have much lee-way before you start getting segfaults.
I can see that getting an update done quickly can help with
contention, but if the algorithm breaks when things arnt done
quickly you're pretty much screwed afaik. I mean theres no way to
guarantee any sequence of instructions gets completed with in
given time frame, on x86 at least.
More information about the Digitalmars-d
mailing list