Architectures with strict alignment?

Erik Trulsson ertr1013 at student.uu.se
Mon Dec 31 05:04:21 PST 2007


On Mon, Dec 31, 2007 at 08:30:35PM +0800, Erich Dollansky wrote:
> Hi,
> 
> Kostik Belousov wrote:
>> On Mon, Dec 31, 2007 at 05:38:43PM +0800, Erich Dollansky wrote:
>>> Kostik Belousov wrote:
>>>> On Sat, Dec 29, 2007 at 01:12:04PM +0200, Kostik Belousov wrote:
>>>>> On Sat, Dec 29, 2007 at 12:14:11AM -0800, Kip Macy wrote:
>>>> I.e., it seems that gcc does not feel too guilty generating unaligned
>>>> half-word writes on i386. :(
>>> this should not be a problem inside a cache line.
>>> 
>>> If the access goes accross two cache lines and the other cache line is 
>>> not in the cache, it becomes real difficult.
>>> 
>>> I can't tell you what the hardware actually does in this case.
>>> 
>>> It should read the second affected cache line into the cache. But what 
>>> happens if the second affected cache line is blocked by another CPU while 
>>> the current CPU blocks the first cache line?
>> 
>> From the manual, 253668, 7.1.1:
>> 
>> I think we might get any half of the operation as a result.
> 
> so, both CPUs are blocked as none can access the other cache line.
> 
> Is there really nothing in a normal PC to handle this?

No, the CPUs are not blocked, and the hardware handles it in a typical
modern multi-core system (so the programmers can't get it wrong.)

If one CPU tries a write that crosses a cache-line boundary then what might
happen (details vary among architectures) is that it will first get one
cache-line, modify it, and write it back to memory.  Then it will handle the
other cache-line.  This way you cannot get any deadlocks, since the CPU is
waiting for at most one cache-line at a time, but you can get inconsistent
results since the write is not atomic.  (Another CPU can modify either
cache-line in the time after the first CPU has handled the first cacheline,
but before it has gotten to the second cacheline.)

There are many other possible solutions as well, but hardware designers are
usually quite careful to make sure deadlocks do not occur.


For more information consult a good book on computer architecture.
The book usually recommended is "Computer architecture: A quantitative
approach" by Hennessy and Patterson.
(A good book on databases or distributed systems might also be useful, since
the problems with locking and concurrent accesses are essentially the same
in all these areas.)

> 
> I do not know. The hardware I developed earlier was able to handle this by 
> aborting both bus cycles.
> 
> It was then task of the operating system to handle this.

That is another possibility, but one which is not used all that much.


-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013 at student.uu.se


More information about the freebsd-hackers mailing list