Theoretically, yes...in practice, you'll probably never see it happen. However when, if, it does you'll be banging your head trying to figure out what went wrong if you don't have proper synchronization. In fact, in multi-process (multi-threaded) applications this is one of the single biggest coding isses, IMO. (More accurately trying to tune said access to a point where it is both reliable and fast).

Look at it like this:

You have multiple processing accessing memory, and therefore there exists the potential for the Kernel to "context switch" in the middle of an instruction. Now, depending on how the read or write is done depends on whether you see a problem.

Lets say your platform uses 32 bit integers. At the very least, on a hardware (CPU instruction) level, you can guarentee the atomic (i.e. single non-context-switchable operation) read/write of only 8 bits of data (more in most cases, but the minimum register size of any CPU used today is probably going to be 8 bits). The CPU intruction set, kernel, compiler, etc all come into play when knowing when gets done when read/writing an integer to/from said shared memory (or in fact any memory). If your architechture can guarentee the atomic read/write of said 32 bits then you're fine. You'll never have a problem because it would be impossible for the application to be switched during the read/write of an integer.

HOWEVER, if it can not, then application 1 could be in the middle of a read or write when the kernel context switches in application 2 and then this incomplete operation is potentially an issue.

The point is, you really don't know what's going on below you and therefore the possibility does exist for this to get confused. This is exactly why semaphores exists to protect and synchronize this access. This way an application knows when its reads/writes can be "safely" done.

For example, let's say a certain platform can only modify 16 bits of data at a time. To tinker with a 32 bit area would require two (or more) operations. If the Kernel allowed a context switch between them, then it'd be possible (although highly unlikely) for the following sequence of events:

process 1: read first 16 bits
process 2: write first 16 bits
process 2: write second 16 bits
process 1: read second 16 bits

now process 1's view is distorted.

While in practice this is probably NEVER going to occur, it could and bugs like these are very hard to track down because reproducing this case would be almost impossible. Best just to code it correctly to insure that everything is ok.