A scoped exclusive global lock class. More...

#include <file_lock.hpp>

Public Member Functions
	file_lock_t ()
	Create an empty (unlocked) lock object.

	file_lock_t (const std::string &path, const bool remote_lock)
	Acquire a lock for the specified file path. More...

	file_lock_t (file_lock_t &&other) noexcept

file_lock_t &	operator= (file_lock_t &&other) noexcept

	file_lock_t (const file_lock_t &other)=delete

file_lock_t &	operator= (const file_lock_t &other)=delete

	~file_lock_t ()
	Release the lock. More...

bool	has_lock () const

Private Types
using	file_handle_t = int

using	mutex_handle_t = void *

Static Private Member Functions
static file_handle_t	invalid_file_handle ()

static mutex_handle_t	invalid_mutex_handle ()

Private Attributes
std::string	m_path

file_handle_t	m_file_handle = invalid_file_handle()

mutex_handle_t	m_mutex_handle = invalid_mutex_handle()

bool	m_has_lock = false

Detailed Description

A scoped exclusive global lock class.

This lock class is intended to be used for granular synchronization of multiple processes that need to access a specific part of a file system, such as a single file or a folder. Locks are expected to be held for a very short time period (typically only for a fraction of a second), during operations such as file renames or writes.

When the lock is created, a global named system object is created (if necessary) and acquired. Once the lock goes out of scope, the system object is released.

After a lock is no longer used by any process, the named system object may or may not be left on the system (depending on the underlying implementation). It is thus up to the user of the lock to guarantee that the necessary cleanup is performed.

Two system object types are supported:

Remote locks: A remote lock is implemented as a lock file that will safely synchronize access to any file system, even a remote network share.

Local locks: A local lock may be implemented as a system synchronization object (e.g. a named mutex or semaphore), that is only guaranteed to be safe for synchronizing file system access on a local system.

: The advantage of a local lock is that on some systems it is faster than a remote lock.

Note: Do not mix the use of remote locks and local locks for synchronizing access to a single file system, since the locks may live in different namespaces and thus are unaware of each other.; On some systems, local locks are implemented as remote locks.

Constructor & Destructor Documentation

◆ file_lock_t()

bcache::file::file_lock_t::file_lock_t	(	const std::string &	path,
		const bool	remote_lock
	)

explicit

Acquire a lock for the specified file path.

Parameters

path	The full path to the lock file (will be created). The path should be a location on the file system to which the process requires access synchronization.
remote_lock	Require the implementation to use a locking mechanism that can synchronize file system access across several OS instances (e.g. use this for network shares).

◆ ~file_lock_t()

bcache::file::file_lock_t::~file_lock_t ( )

Release the lock.

This releases the lock that was held.

Member Function Documentation

◆ has_lock()

bool bcache::file::file_lock_t::has_lock ( ) const

inline

Returns: true if the lock was acquired successfully.

The documentation for this class was generated from the following files:

base/file_lock.hpp
base/file_lock.cpp

Public Member Functions

Private Types