@flp1969
Yes, I think I get what you say. I could've allocated it all at once and probably should've. It seems much simpler. I'll do that from now on, thanks for pointing that out!
However, when it comes to allocating with int map1[10][10], my school has a rule not to do that if the 10 is variable. In my case it is because I read it from the arguments, some execution might have a 800x600 window while another has 1800x1200 and because of that, I have to malloc. I can't use "map[winx][winy]". I could do "map[800][600]" but then my winx winy are useless and I can't allow the user to decide window size through arguments.
Also I suppose I shouldn't have used the term "thread id" since I wasn't talking about the return value, but the mutex-locked sequential variable.
----------------------------------
So I still have a problem. I found a solution through removing O3, for fsanitize=thread, but not for helgrind. Helgrind still tells me "possible data race" without O3.
I went sniffing around and apparently, helgrind can have false positives. I found this post c++ - Is there a data race in this code? - Stack Overflow
I believe I have a false positive here. How can I possibly prove that, other than arguing that from the logic of the instructions in the functions that are threaded, there is absolutely 0 way two threads can be writing to the same memory? It's all I have but it's not enough for some people, even with the confirmation from some printf's put in there to make sure.
If you do not see the point in being this strict about warnings that likely do not pose any problems - I'm of the same opinion. But at least it got me looking...
