510 - Assert-fail if MPI functions are accessed inside scheduled callbacks from within VT

[pnstickne]

When running in a non-release build, MPI access guard will be enabled by default.

These access guards utilize PMPI (ie. exposing MPI symbols first from VT) to intercept MPI calls.

If enabled, a call to [almost] any MPI_* function from a scheduler-executed handler will trigger a vtAssert. (Various MPI calls, such as WTime, Test, Probe, Get_count are excluded from checks for simplification of usages and benign or non-solo nature.)

Code inside VT explicitly grants itself scoped access to MPI functions via RAII hidden behind a conditional macro.

As an alternative/extension to the scope access, could also expose internal vt_MPI_xyz wrappers that would bypass (or disable the guard internally) and use those throughout VT. Would be trivial macro to MPI_xyz when disabled. It also might be possible to do similar with const auto vt_MPI_xyz = MPI_xyz; and rely on an optimizing compiler to elide the proxy call in release build (not guarded) cases.

Fixes #510

[codecov]

Codecov Report

Merging #792 into develop will increase coverage by 0.04%.
The diff coverage is 96.42%.

@@             Coverage Diff             @@
##           develop     #792      +/-   ##
===========================================
+ Coverage    80.02%   80.07%   +0.04%     
===========================================
  Files          342      343       +1     
  Lines        10696    10724      +28     
===========================================
+ Hits          8560     8587      +27     
- Misses        2136     2137       +1     

Impacted Files	Coverage Δ
tests/unit/runtime/test_mpi_access_guards.cc	96.42% <96.42%> (ø)

[PhilMiller]

Looks like this is headed in the right direction. Could we get a negative test added to ensure that the guards actually catch an undesired call?

[pnstickne]

Looks like this is headed in the right direction. Could we get a negative test added to ensure that the guards actually catch an undesired call?

I've been thinking about how to handle such - there are several things that should test 'a vtAssert' occurred, although this is uhh, hard to catch in a test. It would also have to handle the process dying in gtest as state is all dead.

Guess that's 'ASSERT_DEATH' :|

[PhilMiller]

I've rebased this and integrated/merged it with the PR that uses the safe MPI collectives.

It looks like you lost some of Paul's changes - there are things he's commented as done, that are back to what I'd remarked on as needing to change

[lifflander]

I've generated and pushed a full list of 3.1 that includes the missing calls from before.

[lifflander]

Here is an overview of what got changed by this pull request:

Clones added
============
- src/vt/messaging/active.cc  2
         

See the complete overview on Codacy