Re: fibers,questions about thread id and mutation of vectors

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2026 bytes --]



On 06-01-2023 11:20, Damien Mattei wrote:
> Hi,
> is fibers having a way to know the thread number the code is running?
> i, mean the equivalent of omp_get_thread_num(); in openMP.

There's (current-thread), but that's just Guile; it's not 
Fibers-specific.  It's also not a number.  I don't know if it's 
equivalent to omp_get_thread_num.

> Does vector-set! (i read the mutation section of the docand i suppose it is
> wrapped/rewritten for fibers) in fibers

What docs?  Guile fibers doesn't rewrite vector-set!.  I don't see what 
reason it would have to rewrite vector-set! at all.  The only thing it 
rewrites is the suspendable ports stuff, but that's irrelevant here. 
Could you quote the relevant part of the documentation?

> let many thread access a vector
> without time penalty if the index access are differents? (because if index
> are different there is no real concurrency)

I've heard there is some kind of CPU cache migration penalty when 
mutating and reading nearby regions of memory from different CPUs, but 
that's CPU stuff, not fibers-specific or even Guile-specific stuff.

Going by your previous question 'does fibers have a way to determine the 
thread is running on', I'm assuming your vector has entries per-thread 
and the fibers modify the per-thread entry (maybe some kind of 
accumulator?).

Regardless of the time penalty, it's probably unsafe, because due to 
scheduling, the thread on which a fiber runs can change over time -- 
between determining the index and writing to the vector, the thread can 
have changed.  So you'd have to do 'atomic-box-compare-and-swap!' stuff, 
but then you have a time penalty.  Or use 'call-with-blocked-asyncs' 
appropriately to temporarily block preemption.

Anyway, this reads as an 'XY problem' 
(https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem/66378#66378); 
instead of asking about your attempted solution, could you say what 
problem you are trying to solve?

Greetings,
Maxime.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]