3 ms·

> These should all be thread safe (assuming no other threads modifying the list) and I wasn't aware of any documentation that contradicts that. In other words:

• jasode 11y ago
  >In other words: this code would be thread safe if protected by a readers-writers lock or similar synchronization mechanism The outer context can affect whether or not an STL begin()/end() loop needs locks. For example, many programs can be coded to work in phases: main() { setup_lookup_tables(); // phase 1: fill up (write) to lists/vectors/maps analyze(); // phase 2: spawn multiple threads to read the lists/vectors/maps } The code in the analyze() doesn't need to pay for millions of expensive locks+unlocks that slow things down. The programmer knows there are no writers to STL containers in the analyze() phase. With the assumption of no concurrent writers, the programmer can safely spawn a dozen threads with for(list.begin();list.end();) and get 100% determinism. Explicit sequential ordering can let one avoid unnecessary locks. In this limited sense, the loop is multithread safe for multiple readers. However, even with the assumption of no writers to zcmq's "list", you still cannot spawn multiple reading threads of zlist_next() because the cursor itself is mutating inside the list. The result will not be deterministic. That's the type of comparison I was making. You also have a valid point about general multi-threaded code covering all cases (implied concurrent writers).