guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Maxime Devos
Subject: Re: fibers,questions about thread id and mutation of vectors
Date: Fri, 6 Jan 2023 15:12:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1



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: OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]