Idiomatic D using GC as a library writer

[Patrick Schluter]

On Sunday, 4 December 2022 at 23:37:39 UTC, Ali Çehreli wrote:
> On 12/4/22 15:25, Adam D Ruppe wrote:
>
> > which would trigger the write barrier. The thread isn't
> > allowed to complete this operation until the GC is done.
>
> According to my limited understanding of write barriers, the 
> thread moving to 800 could continue because order of memory 
> operations may have been satisfied. What I don't see is, what 
> would the GC thread be waiting for about the write to 800?

I'm not a specialist but I have the impression that GC write 
barrier and CPU memory ordering write barriers are 2 different 
things that confusedly use the same term for 2 completely 
different concepts.

>
> Would the GC be leaving behind writes to every page it scans, 
> which have barriers around so that the other thread can't 
> continue? But then the GC's write would finish and the other 
> thread's write would finish.
>
> Ok, here is the question: Is there a very long standing partial 
> write that the GC can perform like: "I write to 0x42, but I 
> will finish it 2 seconds later. So, all other writes should 
> wait?"
>
> > The GC finishes its work and releases the barriers.
>
> So, it really is explicit acquisition and releasing of these 
> barriers... I think this is provided by the CPU, not the OS. 
> How many explicit write barriers are there?
>
> Ali