RE: 32-bit memory accesses on dual-core dual-Xeon processors
For your first question, I am afraid that it cannot be guaranteed without
any problem. I am not clear about your algorithm, but per my experiences,
a buffer lock is always required for producer-consumer issue. The buffer is
shared to both the producer and the consumer. Race conditions are
impossible to be avoided.
Not true. It is perfectly possible to create a threadsafe producer consumer
queue without using any syncrhonization at all with the following caveats:
- your read and write pointers should be 32 bit on 32 bit platforms.
- there is only one producer.
-there may be n consumers, as long as each consumer has its own read
pointer, and the producer has a means of checking the read pointer of each
consumer.
- the producer does not overwrite an element in the circular buffer if not
all consumers have read it.
Within these constraints, there is no sycnronizatio needed because the only
things for which the atomicity needs to be guaranteed is the update of the
read and write pointers. if you use 32 bit ints as indices in your circular
buffer, this is a given because 32 bit operations are atomic on 32bit or
higher CPUs.
I have created queues like this for a high performance real-time application
on multiCPU machines with 1000s of asynchronous read / write operations per
second.
If you have no logic flaws in your queue code, it is perfectly safe.
For your second question, this is related to the fact how your operating
system deals with the 32 bit application. On Windows 64 bit platforms, a
technology called WOW (Microsoft Windows On Windows 64) can ensure that
your 32 bit application running on Windows 64 bit has the same behavior as
Windows 32 bit, because it works under 32 bit mode. Your application will
be executed as the process "<application name>*32.exe". If you want your
application fully supports 64 bit, you may need to do some changes and use
a 64 bit compiler to re-compile your application.
If 32 bit read / write pointers are used this is not an issue because 32 bit
update operations are atomic. so whether your app is running in 32 or 64 bit
mode is irelevant in this case.
--
Kind regards,
Bruno.
bruno_nos_pam_van_dooren@hotmail.com
Remove only "_nos_pam"