- User Since
- Apr 16 2015, 7:54 AM (283 w, 2 d)
Tue, Sep 15
Mon, Sep 14
Fri, Sep 11
Looks good, besides a few formatting nits.
Wed, Sep 9
Couple of tests needed to check if the implementation works - one with unshackled task encountered before parallel, and another with unshackled task encountered after / between parallels.
Wed, Aug 26
This change causes standalone Windows build to fail:
Mon, Aug 24
Aug 19 2020
Aug 17 2020
The key difference is:
git diff # gives you short patch
git diff -U999999 # gives you full patch
The full patch should have complete source, as opposed to 3 lines above and below the changes for the short patch.
Ugh, sorry I missed that! Fixed.
Aug 12 2020
Aug 11 2020
Could you please provide full diff so that more context is available around the changes?
Aug 5 2020
Aug 4 2020
Though I didn't test this as I don't have MinGW environment at hand.
Jul 21 2020
Jul 20 2020
OK, I will commit the patch in two parts - one pure gtid checks, another one with other arrays/pointers checks.
I think this is historical artifact that can be removed nowadays.
Maybe, to be on the safe side, we can set LIBOMP_COPY_EXPORTS to false by default, as you suggested.
Then later we can remove the copying functionality at all.
Jul 17 2020
Addressed @tianshilei1992 comment - added check of gtid vs array upper bound.
Applied same checks to couple more files.
Jul 16 2020
Jul 14 2020
Jun 29 2020
Jun 22 2020
Jun 14 2020
Jun 12 2020
Jun 10 2020
Jun 4 2020
Jun 1 2020
May 27 2020
May 26 2020
May 25 2020
May 24 2020
Also may worth adding the test just in case.
May 18 2020
May 14 2020
May 12 2020
Joachim, thanks for taking care of this bug.
Apr 15 2020
Apr 13 2020
Sorry, found one more issue.
May worth waiting for a day or two for others' comments, up to you.
Apr 8 2020
I don't see paired memory barrier in a child thread between assigning th.th_local.reduce_data in __kmp_barrier_template() and releasing b_arrived barrier flag that frees parent to go to reduce data. So it might be that the problem could just become lesser probable. Should paired KMP_MB be added after the reduce_data assignment? Or does atomic releasing of a flag serves as a memory barrier? Then my assumption is wrong and second MB is not needed.
Could you please tell which part is monitor thread?
Code under "#if KMP_USE_MONITOR" implements monitor thread which used earlier to control behavior of worker threads. Now it is not used by default, and worker threads follow requested wait policy themselves.
Apr 7 2020
The idea looks feasible to me in general.
Apr 2 2020
Could you please run clang-format on the changes (new lines are too long). Thanks.
Mar 25 2020
Mar 23 2020
Mar 18 2020
Adde check of task tiedness, and comment on why this is needed.
Mar 5 2020
Mar 4 2020
Mar 3 2020
Addressed comments: removed "#if 0" code block; added basic checks for the test.
Mar 2 2020
Feb 21 2020
Addressed Kelvin's comment.
Added full context.
Also added (missed) "value" attribute to Fortran interfaces.
We may need to also loose the internal tough limit of number of threads in the teams construct, which is currently not convenient to overcome. But this needs time to work on..
Jan 23 2020
Jan 20 2020
If possible, please also fix typo in FreeBSD-related code on line 289 of z_Linux_util.cpp (< is used instead of comma).
Jan 15 2020
Having a copy function per type allows us to reuse it, otherwise we have one copy function per static task location (at worst). Either works for me I think.
I also would be OK with either option.
But note that using per-type functions will require more additions to the interface, like:
(..., num_objects, array_of_copy_wrappers, array_of_desctuctor_wrappers, array_of_obj_offsets).
Then the library can iterate over objects to copy-construct them, then iterate to destroy them after the task is complete. Without any possibility of inlining of any wrappers.
Jan 14 2020
the task create and task issue step are
conceptually not separated anymore as it is
I don't think this can work reliably. Because not all C++ objects can be mem-copied.
E.g. an object can keep its own address or reference, and mem-copy will make it broken.
This could be fixed by generating (optional) thunk routine which would create all needed objects
in the library-allocated space, and similar routine which would destroy all the created objects.