3

Using C++, when I create a new object, then 'new' keyword do some locks (since it does some memory allocation, etc). So, I cannot use it directly in a lock-free software.

However, does the 'delete' keyword create any kind of lock?

I'm still using C++98, I think it will work in the same way in C++11;

Juan JuezSarmiento
  • 255
  • 1
  • 8
  • Have a look at this https://stackoverflow.com/questions/2845980/thread-safety-with-heap-allocated-memory – Wander3r Apr 02 '18 at 06:35
  • I don't think it will, delete calls destructor and simply disregard chunk of memory it once instantiated. waiting for someone to expand too. – someone_ smiley Apr 02 '18 at 06:40

2 Answers2

2

The reason for locks in new is, as you say, the memory allocation. If the allocation requires a lock, it is very likely, at least under some circumstances, that the corresponding de-allocation also requires locks. It is of course possible that the de-allocation is lockless, even if allocation requires locks.

Note that delete itself doesn't do locking (neither does new), it is the underlying primitive that does. So if you have a lock-less allocator, then there should be no issues using new and delete. [Presuming the constructor and destructor are lock-less, of course].

Note that placement forms new and delete shouldn't be locking.

Avoiding new and delete (or at least allocations) probably also restricts a huge amount of what you can do. All containers except std::array (in C++11) will perform allocations, for example, so no std::vector, std::string, std::map, etc. Many constructors perform allocations for the object created. And of course, there may be locks in other functions than new and delete - I/O functions often have locks to prevent completely garbled output (but not necessarily guaranteeing the whole output to NOT be garbled, either). Pretty much anything that uses a common shared resource is likely to have locks at some level, be that inside the OS or at the user-mode level.

The C++ standard doesn't really say anything in this regard, it is an implementation detail.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • Thank you for the in-depth explanation :) – Juan JuezSarmiento Apr 02 '18 at 08:26
  • The whole program doesn't have to be lockless. You could use a `std::vector` as long as you aren't growing it in the "hot" part of your code. And even if each thread is growing its own `std::vector`, it grows exponentially so the contention from different threads competing for the allocator lock should be very infrequent unless they all grow / shrink in lock-step. (So every thread's `vector` is the same size and would all re-alloc at the same time.) Anyway, `operator []` on `vector` is fine. (You can't make a shared `std::vector`, and don't consider `atomic>`, that's slow.) – Peter Cordes Apr 05 '18 at 08:12
  • Peter, the problem is I'm coding an VST plugin, which audio thread need to be 100% lock-free. The interface may have locks – Juan JuezSarmiento Apr 08 '18 at 20:06
1

The C++98 standard has no concept of multithreading. It is to the latitude of the implementation to implement thread safety. Also, the standard indicates only how should the program behave.

For example, there are implementations available which don't actually release memory to the OS when calling delete.

This being said, the answer for C++98 is that it might not lock. But it is implementation independent.

In C++11, things are quite different, since the standard introduces the concept of multithreading.

Paul92
  • 8,827
  • 1
  • 23
  • 37