Repository: opencv
Issue: Feature request / evolutionary proposal - abstraction layer for concurrent data containers similar to TBB and PPL
Labels: feature,RFC

# Feature request / evolutionary proposal - abstraction layer for concurrent data containers similar to TBB and PPL

Author: Ryan Wong (@kinchungwong)
Link: TBD
Status: pre-**Draft** 

> Feature request submitted from public - not yet discussed by team

Platforms: **All** 

> This proposal abstracts over concurrent containers (```concurrent_vector```, ```concurrent_queue```, etc) in TBB and PPL so that (1) other platforms can have access to a fallback implementation (2) both OpenCV and its users can access such facility without writing platform-specific ```#ifdef```s.

Complexity: **no estimates** 

> (1) new facility; does not affect existing code
> (2) for platforms already have TBB and PPL, wrapping is trivial
> (3) for other platforms, initial version may use a C++11/14 mutex-based fallback which is inferior but acceptable. A good fallback will be a future evolutionary proposal.
> (4) after implementation, existing code can be migrated to use new facility, gradually
> (5) users of OpenCV will find it useful

# Introduction and Rationale

Several of the Evolutionary Proposals already place a requirement on having such concurrency containers. It is foreseeable that some Evolutionary Proposals may eventually require exposing these containers to OpenCV users.

Specifically: 

 * <b>OE-11, Logging</b>, may require a concurrent queue to: 
   * Latch (buffer) messages,
   * Maintain the cross-thread timestamp order of logging events
 * <b>OE-16, Mini-Halide</b>, may require a task graph (OE-23), which is typically built on top of concurrency containers from TBB and PPL
 * <b>OE-17, New Filter Engine</b>, may require a facility <b>stronger than ```ParallelLoopBody```</b>. An example is diamond task completion dependency (example: parallel task A and B; when both A and B are finished then start task C).
 * <b>OE-23, Task Graph execution engine</b>, same as above.

 # Proposed Solution

## Initial lightweight wrapper capability

 * Applies only to for platforms with TBB or PPL enabled.
 * Interface wrapper for `concurrent_vector`, `concurrent_queue`, `concurrent_unordered_map` in respective framework

## Initial fallback capability

 * Mutex-based wrapper around C++ standard containers

## Future enhancement 

 * A better fallback implementation that satisfies either lock-free or obstruction-free guarantee, in order to match the same guarantees as in TBB and PPL.
 * Actual performance (CPU overhead, RAM overhead) is nice-to-have but do not need to compete with TBB or PPL.

# Impact on existing code, compatibility

The abstraction wrapper code will be new.

May require C++14 or C++17. In other words, ***currently it is unsure whether C++11 can be sufficient***.

Existing code can be migrated to use the new code over a long period of time. Unmigrated code can continue to use platform-specific ```ifdef``` in order to use TBB or PPL.

# Possible alternatives

The status quo. Some code can continue to use TBB or PPL, such as https://github.com/opencv/opencv/blob/master/modules/core/src/parallel.cpp

Inability to give OpenCV users access to these concurrent containers may impede the dependent OEs, namely OE-11, OE-16, OE-17, OE-23.

# References 

(todo)

# Information about proposal author (This section can be removed by the team after review)

I have worked on these things before so I know what is required. However, my ability to contribute code may be subject to a legal release arrangement (that is being discussed) with my former employer. My C++ coding skill is moderately well (enough to have the experience of working on this type of stuff) but probably not world-class.