#2633: SummationByPart's Diff_gv aliased function does ont document which part of the grid the computed derivative is valid
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: bug
Priority: minor
Component:
Comment (by Roland Haas):
Any updates on this?
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2633/summationbyparts-…
#2503: Various small problems with FishboneMoncriefID
Reporter: Gabriele Bozzola
Status: open
Milestone: ET_2023_05
Version: development version
Type: bug
Priority: minor
Component: EinsteinToolkit thorn
Comment (by Roland Haas):
The milestone ET\_2023\_05 having passed on this: Any progress on this?
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2503/various-small-pro…
#2832: possible race condition in LoopControl
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component:
Comment (by Yosef Zlochower):
I am not getting segfaults so far with the new code.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-con…
#2832: possible race condition in LoopControl
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component:
Comment (by Roland Haas):
@{557058:d079f9c2-ad27-47b2-bf4b-ecc6bbe288b0} could you give this a try, please? It removes the SEGFAULT for me, but then this being a Heisenberg type bug, this may be accidental.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-con…
#2832: possible race condition in LoopControl
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component:
Comment (by Erik Schnetter):
We don’t need `new` or `std::vector`. We replace the call to `new` with `posix_memalign`, and the call to `delete` by `free`. Then each thread has one cache line as intended.
Alternatively, there could be one call to `posix_memalign` allocating memory for all threads, and each thread uses pointer arithmetic to find its place.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-con…
#2832: possible race condition in LoopControl
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component:
Comment (by Roland Haas):
Minor point: Padding size wise I think just adding and _extra_ 128 bytes \(or whatever the cache line size is\) instead of padding to 256 \(twice the cache line size\) should be sufficient to ensure that there are no shared cache lines since even in the worst case scenario where the first structure member is a the very end of a cache line padding by a full cache line size skips into the next cache line for the next array member \(which will start somewhere near the beginning of its cache line of then\).
`posix_memalign` might be more efficient. Would still need a comment like right now since we do not want alignment but separation.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-con…
#2832: possible race condition in LoopControl
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component:
Comment (by Roland Haas):
Right, I was thinking of it but did not consider it as likely to pass the smell test. Namely: how to nicely combine that one with `std::vector`? Works fine to replace the naked `new` of course. For the `std::vector` one would use something like this:
```
lc_fine_thread_comm_t lc_fine_thread_comm = nulltpr;
[...]
if (!lc_fine_thread_comm) {
lc_fine_thread_comm = static_cast<lc_fine_thread_comm*>(posix_memalign(n*sizeof(*lc_fine_thread_comm), 128));
for(size_t i = 0 ; i < n ; ++i) {
lc_fine_thread_comm_t* ptr = new (lc_fine_thread_comm+i) lc_fine_thread_comm_t();
assert(ptr == lc_fine_thread_comm+i); // apparently not guaranteed
}
}
```
and similar awkwardness if we ever were to `free` the array.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-con…