Recommendations are off-topic for StackOverflow, but you should peruse Software Recommendations. — Thomas Matthews 47 secs ago

hey what's up, thanks again for helping me fix my problem! you're the best software engineer i've met here so far. i appreciate you. — Jaecelle Domingo 49 secs ago

You might find the question of how to weigh the trade-offs is better suited to Software Engineering or possibly Project Management. — eggyal 1 min ago

😁Welcome! Happy to help. I am still learning and trying my best to become what you call a "Software Engineer". — Abdur Rehman 33 secs ago

This is likely to get closed as too broad, I suspect. See also Why is “Is it possible to…” a poorly worded question? — ADyson 33 secs ago

It is a fairly certain bet that the authors of the standard library will have worked quite a long time on making strcmp very optimized. Few programmers will be able to beat most standard-library implementations. — Some programmer dude 58 secs ago

@Adrian Go's mutexes work the same as C mutexes I read the source code you gave me and I found runtime_doSpin() in it. It seems the implementation uses spinlock while, as far as I understand, C's implementation uses blocking (spin vs blocking). Now I understand they are actually different and the difference makes it possible to block only the current goroutine. — ynn 53 secs ago

@pm100 Side note: I'm on a personal quest to stamp out oddball arches that torture C and programmers. TI DSPs (char==16 bits), Intel 8051 (uses different insts and different sizeof for pointers), PIC* (banked memory), Sperry/Univac/Burroughs (36 bit words), PDP/8 (self modifying code on call/return). The "stamp" list is "do not use in future designs" and "replace all existing boards". May I ask what CPU/arch you're referring to so I can add it to the list? ;-) — Craig Estey 1 min ago

I am sorry for asking my question here But I need to know the opinion of the programmers in this place. — Hami Zahedi 19 secs ago

I changed nothing. The point is you should acknowledge with a slight change in environment (e.g. GPU) your code can produce different results. Probably most programmers don't want such a behavior. It is cause for concern. Conditioning access means you should observe that multiple CUDA threads can both read and write edges[i].flow at any specific time, and you are not controlling that behavior at all. CUDA doesn't sort that out for you, and that generally may give rise to a race condition in any parallel multithreaded programming model. You may need to learn more about race conditions. — Robert Crovella 35 secs ago