Unnecessary locking in STL? (Visual C++ Express)

I'm trying to build a Tetris AI algorithm th开发者_StackOverflow社区at can scale over multiple cores.

In my tests it turns out that using multiple threads is slower than using a single thread.

After some research I found that my threads spend most of their time waiting for _Lockit _Lock(_LOCK_DEBUG). Here's a screenshot.

As you can see, the lock is applied on a local variable, which shouldn't require any locking anyway!

My questions are:

• Why does STL lock this vector?
• How can I make my program faster? (Use arrays?)

Update

I eliminated the lock by setting these command line options in my Visual Studio projects:

/D "_HAS_ITERATOR_DEBUGGING=0" /D "_SECURE_SCL=0"

It's important to apply this to all projects in the solution file or errors will occur at runtime (conflicting iterators etc).

The second thing I changed was changing std::vector<bool> into std::vector<char>. I wasn't aware that std::vector<bool> was so slow.

---

If you're spending time in LOCK_DEBUG, then you are using the debugging iterators. These iterators all track their positions and parent containers, and detect several cases of undefined behavior for you. They do, however, impose a runtime cost.

Compile in release mode and see if that's still a bottleneck. There might be an additional switch or #define required to turn them off too -- not positive.

Any other locking is going to actually be required for correct operation -- when you're reading from the vector, you must ensure nobody is writing to that vector at the same time (at least to get the kind of thread safety expected of most STL implementations -- namely that different readers are safe, even though multiple writers are not). That requires locking to maintain.

Also consider not using vector<bool> (use a deque<bool> or a vector<char> or vector<int> instead), as it usually requires more threading overhead because it stores pseudo-bools in individual bits. That lets it fit more in less space but unfortunately means that reads and writes to the container are no longer atomic, which could require more locking.