[WIP] fmsolvr eventify: removed ObjectWrapper #10

Merged

i.kabadshow merged 6 commits from m.zych/fmsolvr:WIP/parallelization/intra-node/lgpl21+minimize into WIP/parallelization/intra-node/lgpl21+minimize

2021-04-02 00:11:28 +02:00

m.zych commented

2021-04-02 00:08:53 +02:00

Member

No description provided.

m.zych added 6 commits

2021-04-02 00:08:54 +02:00

[WIP] eventify: removed unused template parameter ObjectWrapperTreeType 3041c5692e

[WIP] fmsolvr: parameterized octree with the node_type 846ca849d8

The octree is a generic container,
which stores elements of any type as its nodes.

The fact that FMSolvr instantiates only octrees parameterized by:
 - counter_tuple_wrapper<tuple>
 - ObjectWrapper<ObjectType, ObjectAccessStrategy>
 - MultipoleCoefficients[Upper, UpperLower]<Real>
which apparently were considered containers, is completely irrelevant,
because the octree should be oblivious to how FMSolvr is using it.

Moreover, the octree should define its size_type
based on properties of its implementation, to ensure that
storing maximum supported number of elements is handled correctly.

Concretely, the octree theoretically supports storing as many elements,
as there are bytes in the virtual address space,
therefore the std::size_t type was chosen as octree's size_type.

Lastly, the octree should *not* assume that
the node_type contains nested size_type,
since the octree should support fundamental data types: int, float, etc.

[WIP] fmsolvr: eliminated redundant usage of the ObjectWrapper 2276298797

The Eventify tasking system assumes that tasks are functions,
which can be executed as soon as their dependencies are met.

Consequently, when tasks access state shared with other tasks,
and *do not* express this via dependencies between tasks,
they need to synchronize access to the shared state themselves,
outside of the tasking system, using suitable synchronization primitive.

This implies that ObjectWrapper and MutexContainer
are not really integral components of the Eventify tasking system,
instead they belong to internal data structures of the FMSolvr.

Moreover, an ObjectWrapper stores not only a mutex, but also a reference,
via which the shared object is accessed under the lock,
even though in all contexts, where ObjectWrapper is used in FMSolvr,
access to the shared object is already available.
This makes usage of the ObjectWrapper in FMSolvr completely unnecessary.

Lastly, relying on such a complicated mechanism to simply lock() a mutex,
is a maintanance and comprehension burden, which could be easily avoided,
by using std::scoped_lock from the C++ standard library.

[WIP] fmsolvr: removed unused octree constructor taking coupled_tree b8d65782dd

[WIP] eventify: removed unused ObjectAccess mechanism 6f5fb92aa4

Accessing an object via the ObjectAccess token,
aquired from the ObjectWrapper, using some ObjectAccessStrategy,
could be essentially understood as a general mechanism of
accessing an object indirectly via some sort of special means, such as:

 - accessing an object only when under a lock
 - accessing an object using set of per thread copies, combined at the end
 - accessing an object remotely via network
 - accessing an object serialized to a file
 - accessing an object residing in a GPU memory

The issue with this approach is, writing efficient generic code,
adhering to the zero-overhead principle for all access strategies,
is next to impossible, since different access strategies could have
vastly different performance characteristics of the following operations:

 - creating an accessor
 - accessing an object through the accessor
 - destorying an accessor

[WIP] fmsolvr: replaced manual locking with std::scoped_lock 4005283009

Note that, in contrast to pass2 and pass3, pass4 and pass5 were *not*
using ObjectWrapper to synchronize access to their shared state.

i.kabadshow merged commit 4005283009 into WIP/parallelization/intra-node/lgpl21+minimize

2021-04-02 00:11:28 +02:00

No reviewers

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: ATML-CAP/fmsolvr#10

No description provided.

Rows
Columns