__sync_synchronize stops processor ?
-
I am "porting" C code into C++, mainly to gain an experience. Run into this , undocumented , piece of code. Did some reading and have basic understanding WHAT is suppose to do. Preventing multiprocessors to clobber each other or multiple access to shared devices / memory. So far my software is for single CPU and no sharing of I/O , not yet. That is NOT my concern. What I would like to know why it stops running the process PAST the first usage of __sync_synchronize(); It compiles just fine.
\_\_sync\_synchronize(); STOPS HERE ret = \*paddr; \_\_sync\_synchronize();Thanks Cheers Vaclav
-
I am "porting" C code into C++, mainly to gain an experience. Run into this , undocumented , piece of code. Did some reading and have basic understanding WHAT is suppose to do. Preventing multiprocessors to clobber each other or multiple access to shared devices / memory. So far my software is for single CPU and no sharing of I/O , not yet. That is NOT my concern. What I would like to know why it stops running the process PAST the first usage of __sync_synchronize(); It compiles just fine.
\_\_sync\_synchronize(); STOPS HERE ret = \*paddr; \_\_sync\_synchronize();Thanks Cheers Vaclav
Hi, You obviously have a race condition somewhere in your code. As you have probably discovered... that intrinsic function is a memory barrier. There's no way to fix this without learning how to debug your code. If you are developing on the Windows platform then fire up WinDbg and attach it to the process and type '!locks' Debugging a Deadlock[^] Best Wishes, -David Delaune
-
Hi, You obviously have a race condition somewhere in your code. As you have probably discovered... that intrinsic function is a memory barrier. There's no way to fix this without learning how to debug your code. If you are developing on the Windows platform then fire up WinDbg and attach it to the process and type '!locks' Debugging a Deadlock[^] Best Wishes, -David Delaune
-
David, thanks for reply. Upon further invetsigation I believe "my problem" is elsewhere in code since it stops on the line between the calls to the __sync_synchronize. Vaclav
Well, Yes; deadlocks, race conditions by the very definition means "somewhere else" is holding a lock. You are looking at the code not me. But I wouldn't recommend using the "Current Line" in the source-view as my error indicator. You need to be looking at the callstack and instructions. My recommendations remain: Attach a debugger to the process. If you want an automated analysis of the deadlock you can attach WinDbg and do: analyze -v -hang Are you developing on Windows? My mind reading skills are not working today. Best Wishes, -David Delaune
-
Well, Yes; deadlocks, race conditions by the very definition means "somewhere else" is holding a lock. You are looking at the code not me. But I wouldn't recommend using the "Current Line" in the source-view as my error indicator. You need to be looking at the callstack and instructions. My recommendations remain: Attach a debugger to the process. If you want an automated analysis of the deadlock you can attach WinDbg and do: analyze -v -hang Are you developing on Windows? My mind reading skills are not working today. Best Wishes, -David Delaune