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

[Damien Mattei]

when void is not empty , the solution was to replace (list void) with '()
:-)

(define omp-get-max-threads
  (pointer->procedure int
                      (dynamic-func "omp_get_max_threads" libomp)
                      '()))


On Fri, Jan 6, 2023 at 4:06 PM Damien Mattei <damien.mattei@gmail.com>
wrote:

> yes sorry i misunderstand the fiber doc about mutation:
> https://github.com/wingo/fibers/wiki/Manual#Mutation
> set! and vector-set! are not wrapped.(i imaginate it ...)
>
> reply continue below:
>
> On Fri, Jan 6, 2023 at 3:12 PM Maxime Devos <maximedevos@telenet.be>
> wrote:
>
>>
>>
>> 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.
>>
>
> no it returns something based on address:
> scheme@(guile-user)> (current-thread)
> $1 = #<thread 8814535936 (102a61d80)>
> the good thing it is that it is different for each address, the bad is
> that i do not know how to extract it from the result and anyway i need a
> number : 0,1,2,3... ordered and  being a partition to make scheduling that
> each thread deal with a part of the array (vector) the way it is in OpenMP
> like in the FOR example i posted a week ago
>
>>
>>
>> > 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.
>>
>
> yes it is true
>
>>
>> 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.
>
>
> ! if the code change of thread the organisation of computation is
> completely broken
> in OpenMP (and GPUs too) a thread keep it jobs until it is finished , data
> are sliced between threads at beginning, each thread use its number id  to
> retrieve and compute the data of the array (array defined in shared memory)
> there is no concurrency (unless in cpu cache as you mentioned it but i do
> not know how openMP deal with that) as each thread use separate regions of
> the array (vector)
>
>> 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?
>>
>
> just do a 'for like in openMP (mentioned above)
> i undertand fibers is better for scheduling web server request but not for
> parallelizing like openMP - it is two differents world.
>
> Regards,
> Damien
>
> note: a little question again:
> i try to use
>
> int omp_get_max_threads(void);
>
> https://www.openmp.org/spec-html/5.0/openmpsu112.html
>
> from guile with:
> (define libomp (dynamic-link "libomp"))
>
> (define omp-get-max-threads
>   (pointer->procedure int
>                       (dynamic-func "omp_get_max_threads" libomp)
>                       (list void)))
>
> but i get this error:
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure pointer->procedure: Wrong type argument in position 3: 0
>
> i do not understand why.
>
>
>> Greetings,
>> Maxime.
>>
>