hi all,

if I had 2 Procs (Proc1 and Proc2) and Proc1 was trying to write to a variable while Proc2 was trying to read the same variable, would there be a memory violation?

This is what I'm trying to do:

I have 9 variables (s1,s2,s3,s4,s5,s6,s7,s8, and s9)
each variable is of type CUSTOM:

Count as DWORD
End Type

This means that s1 (for example) would have 2 members:
s1.Count (32bits)
s1.ID (1byte)

Now, I have Proc1 which updates the variables (based on where the mouse position is) but AT THE SAME TIME Proc 2 is running and is trying to figure out which variable has the highest value in the .Count member (this means that Proc2 has to read the .Count member for variables s1 - s9) but at the same time, again, proc1 is updating the value in .Count for specific variables depending on where the mouse position is.

Any ideas on whether a memory access violation will occur?
Posted on 2003-12-13 11:38:58 by quaze
If two procs were trying to write to a variable at the same time, would there be a memory access violation or does the processor have some way of executing each write procedure sequentially as opposed to synchronously?

Thanks in advance for your help.
Posted on 2003-12-13 11:42:29 by quaze
If I am not wrong, prefix the instruction with lock.
Posted on 2003-12-13 12:02:06 by roticv
Hi. :)
The processor really never executes anything synchronously. It just seems to do so... but in reality it quickly "switches" from one thread to the other. So you might have a synchronization problem if one thread is reading data from a structure, but another thread still didn't finish updating the data when the processot "switched". You might want to read Iczelion's tutorials, they cover this very well.

I'm assuming that you're using a global mouse hook, right? You might also want to check this:


Posted on 2003-12-13 12:07:08 by QvasiModo
Also, memory access violations occur when you access memory in a way your process was not allowed to. If two threads of any process rightfully access the same variable in memory, nothing happens.
Posted on 2003-12-13 12:08:36 by QvasiModo
do you mean "usual" one CPU machine?
Posted on 2003-12-13 12:29:05 by The Svin
make sure u don't write / read the same time with 2 procs,
look at 'semaphore' algorithms, on how to keep shared 'data' access violation/crashes free
Posted on 2003-12-14 00:58:57 by wizzra
Thank you all for your very useful hints ...

The Svin, it is just 1 CPU, yep.
Thank you :)
Posted on 2003-12-14 01:02:28 by quaze
As Qvasi said there isn't really simultainous thread execution on single processor machines (with the exception of P4 with HT Technology *bing, bing, bong, bing, bong!*). The processor time-slices so it switches very rapidly between all tasks which are demanding attention, it's a kind of slight of hand really.
Multi-processor machines and the P4HT do actually execute several simlutainiously, and if someone were to ever run your non-thread-safe code on one of those machines Bad ThingsTM may happen. What should happen is that the two processes end up in a race condition, where one will win. Further accesses may then of course hold the wrong result.
It could well be possible that you fetch the count say, and store it in a register. By the time you've incremented and written it back, the other process could have decremented it AND stored it back. Thus when you come to store back the incremented version it writes over the top of the decremented one.

The OS provides functional level thread-exclusivity via Mutex (mutually exclusive) functions. They will bar another thread from executing at the same time. This will eliminate any of these functions, and is truely safe. Lock will not stop the memory from being accessed while it is being held in a register.

Posted on 2003-12-14 12:39:10 by Mirno
forgive my ignorance but would you be able to post an example on how to use mutex?

If not, it's ok. You've all been very helpful as it is.

Thanks again ...
Posted on 2003-12-15 11:55:30 by quaze

A mutex object is a synchronization object whose state is set to signaled when it is not owned by any thread, and nonsignaled when it is owned. Only one thread at a time can own a mutex object, whose name comes from the fact that it is useful in coordinating mutually exclusive access to a shared resource. For example, to prevent two threads from writing to shared memory at the same time, each thread waits for ownership of a mutex object before executing the code that accesses the memory. After writing to the shared memory, the thread releases the mutex object.

A thread uses the CreateMutex function to create a mutex object. The creating thread can request immediate ownership of the mutex object and can also specify a name for the mutex object. Threads in other processes can open a handle to an existing mutex object by specifying its name in a call to the OpenMutex function. For additional information about names for mutex, event, semaphore, and timer objects, see Interprocess Synchronization.

Any thread with a handle of a mutex object can use one of the wait functions to request ownership of the mutex object. If the mutex object is owned by another thread, the wait function blocks the requesting thread until the owning thread releases the mutex object using the ReleaseMutex function. The return value of the wait function indicates whether the function returned for some reason other than the state of the mutex being set to signaled.

Once a thread owns a mutex, it can specify the same mutex in repeated calls to one of the wait-functions without blocking its execution. This prevents a thread from deadlocking itself while waiting for a mutex that it already owns. To release its ownership under such circumstances, the thread must call ReleaseMutex once for each time that the mutex satisfied the conditions of a wait function.
If a thread terminates without releasing its ownership of a mutex object, the mutex object is considered to be abandoned. A waiting thread can acquire ownership of an abandoned mutex object, but the wait function's return value indicates that the mutex object is abandoned. It is best to assume that an abandoned mutex object indicates that an error has occurred and that any shared resource being protected by the mutex object is in an undefined state. If the thread proceeds as though the mutex object had not been abandoned, its "abandoned" flag is cleared when the thread releases its ownership. This restores normal behavior if a handle to the mutex object is subsequently specified in a wait function.

Multiple processes can have handles to the same event, mutex, semaphore, or timer object, so these objects can be used to accomplish interprocess synchronization. The process that creates an object can use the handle returned by the creation function (CreateEvent, CreateMutex, CreateSemaphore, or CreateWaitableTimer). Other processes can open a handle to the object by using its name, or through inheritance or duplication.
Posted on 2003-12-16 03:45:28 by wizzra