Update versions for v33r2

See merge request gaudi/Gaudi!1083

Fixes for ROOT master

See merge request gaudi/Gaudi!1071

Use fmtlib instead of boost::format (where possible)

Closes #112

See merge request gaudi/Gaudi!1046

Conditions alg test, with stall debug info

See merge request gaudi/Gaudi!1092

see https://sft.its.cern.ch/jira/browse/ROOT-10771

Make sure the TES is cleaned by EventLoopMgr before finalize

Closes LHCBPS-1850

See merge request gaudi/Gaudi!1082

Fix race condition between tests

See merge request gaudi/Gaudi!1074

Fix propagation of StopIteration exception

Closes #129

See merge request gaudi/Gaudi!1093

Update HiveDataBroker to use C++20 ranges if available.

See merge request gaudi/Gaudi!1089

Scott Snyder authored 4 years ago and Marco Clemencic committed 4 years ago

gcc 10 in C++20 mode gives errors on the range-v3 code in HiveDataBroker.cpp.
However, gcc 10 has C++20 ranges, so switch to using that implementation
instead if it is available.  In so doing, we need to change remove_if
to filter, as the former isn't in C++20 ranges.

Fixes for c++20

See merge request gaudi/Gaudi!1085

Scott Snyder authored 4 years ago and Marco Clemencic committed 4 years ago

  - Three-way comparison.
  - Typedefs removed from std::allocator

Fix thread-safety problem in GaudiHandle

See merge request gaudi/Gaudi!1084

Scott Snyder authored 4 years ago and Marco Clemencic committed 4 years ago

The component retrieval code in GaudiHandle can lead to operator->()
returning a null pointer for a valid handle, if it is called
simultaneously from multiple threads.

The relevant code in GaudiHandle is:

```
  T* operator->() {
    assertObject();
    return m_pObject;
  }

  void assertObject() const {
    if ( UNLIKELY( !isValid() ) ) {
       throw GaudiException ...
    }
  }

  bool isValid() const {
    // not really const, because it may update m_pObject
    return m_pObject || retrieve().isSuccess();
  }

  StatusCode retrieve() const {
    // not really const, because it updates m_pObject
    StatusCode sc = StatusCode::SUCCESS;
    if ( m_pObject && release().isFailure() ) { sc = StatusCode::FAILURE; }
    if ( sc && retrieve( m_pObject ).isFailure() ) {
      m_pObject = nullptr;
      sc        = StatusCode::FAILURE;
    }
    return sc;
  }
```

Note that if the pointer is already set when retrieve() is called, it
clears it and redoes the lookup.

So we could have:

```
  thread 1 calls operator->.  m_pObject is not set, so it executes
  through to retrieve() after the test on m_pObject.

  thread 2 calls operator->.  m_pObject is not set, so it executes
  through to the start of retrieve().

  thread 1 continues, does the lookup, sets m_pObject and returns.

  thread 2 continues, tests m_pObject, finds it set, and calls reset()
  to clear it.

  thread 1 continues, returning through operator->.  m_pObject is now
  null, so it returns null.

  thread 2 continues with the retrieve, and returns a valid pointer
  from operator->.
  ```

I've tentatively tried to fix this by making m_pObject atomic, and
changing retrieve() so that it will not change m_pObject if it is
already set.  I think that's consistent with what's implied
by retrieve() being const.  ATLAS software seems fine with this change,
but this is, however, a potential change of behavior, so i point
it out here.

Misc. Sanitiser improvements

See merge request !1081

make GaudiHandleArray.__str__ consistent with GaudiHandle.__str__

See merge request !1070

Fix trivial typo in message.

See merge request gaudi/Gaudi!1087