1

Let a thread declare a lock (v. gr. std::unique_lock<std::mutex>) to try to own a certain mutex. If contention, that thread will be added to a list of threads waiting for that mutex to be unlocked.

How long can that list get?

Considering that the actual length might differ between implementations, I'm just interested in knowing what is the order of magnitude. And if it is limited by stack size or memory?

While learning about mutexes and conditional variables, I figured that a particular implementation of a processing buffer could just generate a pool of threads with one lock per thread of the same mutex.

I understand that there is no actual limitation to the number of threads running simultaneously other than physical memory. So, is there, perhaps limitation in terms of the queue of threads waiting to acquire a single mutex?

I'm just curious. I'm not thinking of implementing this design... or maybe that is precisely why I should play with it and see its limitations, its "hackyness" and observe probably unforeseen problems with it. Is this a common design option?

Thank you,

johnnybegood
  • 321
  • 3
  • 7
  • 1
    I don't think this is a [C++] question. I am not aware the C++ standard would impose any such limits. I guess this question should be related to some operating system, such as Linux or Windows. – Daniel Langr Jun 17 '21 at 06:01
  • 2
    Why don't you just try it out? – Jodocus Jun 17 '21 at 07:53
  • 1
    If your question is OS-specific, can you add a tag for the appropriate operating system. – Daniel Dearlove Jun 17 '21 at 09:21
  • 1
    Give it a go. Post the spec of your machine, the code and the benchmarks. I would be interested to know how slow you can make your machine with all the context switches before the kernel blows up. – Daniel Dearlove Jun 17 '21 at 09:25

1 Answers1

1

I think there is a partial answer here for Linux machines. It depends on the limits applied to every process. Call ulimit in a terminal to see them.

Daniel Dearlove
  • 565
  • 2
  • 12