I have a single threaded program that does heavy processing, writes to a file, then resumes heavy processing. On a Pentium III 1066 running Windows XP, the data is not saved properly. How can I pause the processing until the data is written please?
I have a dual threaded version of this program. Can I signal the second thread to HLT until resumed? Then how can it be resumed please.
Thanks.
I have a dual threaded version of this program. Can I signal the second thread to HLT until resumed? Then how can it be resumed please.
Thanks.
HLT is a privileded instruction. There are plenty of synchronization methods on Windows OSes.
VCoder, the data isn't saved properly even if you call WriteFile? Have you set your thread priority to realtime or something similarly foolish?
VCoder, the data isn't saved properly even if you call WriteFile? Have you set your thread priority to realtime or something similarly foolish?
Nope. Priority is set to Normal or can be set to Idle. The program calls the save routine, which writes and closes the files (which can be up to hundreds of MB at this time). Upon return from save, the program immediately picks back up processing.
...and still the data isn't saved correctly? This sounds very weird. Have you run chkdsk lately?
Are you synchronizing the access to the data-to-be-saved properly?
Are you synchronizing the access to the data-to-be-saved properly?
Why not use the old mutex trick. Create a global variable which takes two states (that being said it doesn't even have to take up much room, it can be a single byte). Then when you begin accessing the file, place the byte into an on state, so that when anything else tries to access it, they will fail.
As shown in the above code, you can create two threads using the same procedure, but the procedures will only really processes the code one at a time, because the second time the procedure is ran, it will become stuck in the while loop until the procedure finishes and sets the g_lock state to STATE_OFF which will break the while look of the second procedure being ran.
SO, in your case, you could have your procedure which does the heavy processing run, with very few breaks using the while loop above, then when your File writing begins, simple activate the g_lock which will pause execution of your other procedure until the g_lock variable is turned back off.
Regards,
Bryant Keller
STATE_ON equ 1
STATE_OFF equ 0
.data
g_lock db STATE_OFF
...
.code
ProcedureOne proc
.while ( g_lock == STATE_ON )
invoke Sleep, 200
.endw
mov g_lock, STATE_ON
; do your processing
mov g_lock, STATE_OFF
ProcedureOne endp
...
As shown in the above code, you can create two threads using the same procedure, but the procedures will only really processes the code one at a time, because the second time the procedure is ran, it will become stuck in the while loop until the procedure finishes and sets the g_lock state to STATE_OFF which will break the while look of the second procedure being ran.
SO, in your case, you could have your procedure which does the heavy processing run, with very few breaks using the while loop above, then when your File writing begins, simple activate the g_lock which will pause execution of your other procedure until the g_lock variable is turned back off.
Regards,
Bryant Keller
Better use a CRITICAL_SECTION instead of handcoding it...
Thanks for the tip f0dder, I wasn't actually aware that there was a WinAPI for doing mutex's, of course I've not done any multithreading code since I was assisting in the design of a C HTTP server using mutex_lock() and mutex_unlock()
There's lots of neat synchronization APIs in windows. The nice thing about critrical sections is that first it'll try "spinning" for the lock, and if it doesn't get the lock fairly soon it'll WaitForSingleObject (ie, 0% CPU time until the lock is freed). The spinning is done to avoid a costly user->kernel->user transition if the lock is released fast.