# V1088\. No objects are passed to the 'std::scoped\_lock' constructor\. No locking will be performed\. This can cause concurrency issues\.

The analyzer has detected a problem\. An object of the 'std::scoped\_lock' type is constructed without arguments passed to it — i\.e\., without lockable objects\. This can lead to problems in a multithreaded application: race condition, data race, etc\.

Since C\+\+17, the standard library has '[std::scoped\_lock](https://en.cppreference.com/w/cpp/thread/scoped_lock)' class template\. It was implemented as a convenient alternative to '[std::lock\_guard](https://en.cppreference.com/w/cpp/thread/lock_guard)'\. We can use 'std::scoped\_lock' when we need to lock an arbitrary number of [lockable objects](https://en.cppreference.com/w/cpp/named_req/Lockable) at a time\. The class provides an [algorithm](https://en.cppreference.com/w/cpp/thread/lock) that prevents deadlocks\.

However, the new design has certain disadvantages\. Let's see how we can declare one of its constructors:

```cpp
template <class ...MutexTypes>
class scoped_lock
{
  // ....
public:
  explicit scoped_lock(MutexTypes &...m);
  // ....
};
```

The constructor receives an arbitrary number of arguments of the 'MutexTypes' \(parameter pack\) type\. The parameter pack 'MutexTypes' can be empty\. As a result, we can get a RAII object without locks:

```cpp
void bad()
{
  // ....
  std::scoped_lock lock;
  // ....
}
```

To fix this, we should initialize 'std::scoped\_lock' with a lockable object:

```cpp
std::mutex mtx;

void good()
{
  // ....
  std::scoped_lock lock { mtx };
  // ....
}
```