1

Do we need any synchronization, if multiple threads access 

pair<iterator,iterator> equal_range (const value_type& val) const;

Since equal_range is a read operation, it may not be required. Please comment.

juanchopanza
  • 223,364
  • 34
  • 402
  • 480
user2586432
  • 249
  • 1
  • 4
  • 12
  • 1
    @JerryYYRain Please don't make nonsensical edits. What's worse is this stuff actually gets approved by **3** people. – Praetorian Jun 14 '14 at 07:43
  • @Praetorian And it seems they keep the edit brownie points, even if the edit gets rolled back. – juanchopanza Jun 14 '14 at 07:46
  • @user2586432 Do you mean `pair equal_range (const value_type& val) const;`? – juanchopanza Jun 14 '14 at 07:50
  • Assuming you're talking about the overload that juan posted in the comments, then yes, the [access should be thread safe](http://stackoverflow.com/a/14127380/241631). – Praetorian Jun 14 '14 at 07:52

1 Answers1

2

Like you said, since you are only "reading data" you don't need any synchronization, you can expect the function to be "thread-safe", see this question where the accepted answer states:

[17.6.5.9/3] A C++ standard library function shall not directly or indirectly modify objects (1.10) accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function’s non-const arguments, including this.

Community
  • 1
  • 1
Étienne
  • 4,773
  • 2
  • 33
  • 58
  • Huh? Since when does "only reading data" imply thread safety? Const does not guarantee that things don't change internally. For example it could cache a value internally. – tenfour Jun 14 '14 at 09:46
  • @tenfour You are right in the general case, but not in the context of this question. const actually guarantee that things don't change internally in the case of the standard library: http://stackoverflow.com/questions/14127379/does-const-mean-thread-safe-in-c11/14127380#14127380 – Étienne Jun 14 '14 at 10:07