Documentation - C API
Threading

Table of Contents

VLFeat supports for threaded computations can be used to take advantage of multi-core architectures. Threading support includes:

Using VLFeat from multiple threads

VLFeat can be used from multiple threads simultaneously if proper rules are followed.

  • A VLFeat object instance is accessed only from one thread at any given time. Functions operating on objects (member functions) are conditionally thread safe: the same function may be called simultaneously from multiple threads provided that it operates on different, independent objects. However, modifying the same object from multiple threads (using the same or different member functions) is possible only from one thread at any given time, and should therefore be synchronized. Certain VLFeat objects may contain features specific to simplify multi-threaded operations (e.g. VlKDForest).
  • Thread-safe global functions are used. These include thread-specific operations such as retrieving the last error by vl_get_last_error and obtaining the thread-specific random number generator instance by vl_get_rand. In these cases, the functions operate on thread-specific data that VLFeat creates and maintains. Note in particular that each thread has an independent default random number generator (as returned by vl_get_rand). VLFeat objects that involve using random numbers will typically use the random number generator of the thread currently accessing the object (although an object-specific generator can be often be specified instead).
  • Any other global function is considered non-thread safe and is accessed exclusively by one thread at a time. A small number of operations are non-reentrant and affect all threads simultaneously. These are restricted to changing certain global configuration parameters, such as the memory allocation functions by vl_set_alloc_func. These operations are not thread safe and are preferably executed before multiple threads start to operate with the library.

Parallel computations

VLFeat uses OpenMP to implement parallel computations. VLFeat avoids changing OpenMP global state, such as the desired number of computational threads, as this may affect the rest of the application (e.g. MATLAB) in undesriable ways. Instead, it duplicates OpenMP controls when appropriate (this is similar to the method used by other libraries such as Intel MKL).

The maximum number of threads available to the application can be obtained by ::vl_get_thread_limit. This limit is controlled by the OpenMP library (the function is a wrapper around omp_get_thread_limit), which in turn may determined that based on the number of computational cores or the value of the OMP_THREAD_LIMIT variable when the program is launched.

The desired number of computational threads is set by vl_set_num_threads() and retrieved by vl_get_max_threads(). This number is a target value as well as an upper bound to the number of threads used by VLFeat. vl_set_num_threads(1) disables the use of multiple threads and vl_set_num_threads(0) uses OpenMP value (retrieved by calling omp_get_max_threads()). The actual number used in a specific computation is decided by OpenMP based on the number of threads available, accounting for example for nested parallelism when appropriate.

See also:
http://software.intel.com/sites/products/documentation/doclib/mkl_sa/11/mkl_userguide_win/GUID-C2295BC8-DD22-466B-94C9-5FAA79D4F56D.htm http://software.intel.com/sites/products/documentation/doclib/mkl_sa/11/mkl_userguide_win/index.htm#GUID-DEEF0363-2B34-4BAB-87FA-A75DBE842040.htm http://software.intel.com/sites/products/documentation/hpc/mkl/lin/MKL_UG_managing_performance/Using_Additional_Threading_Control.htm