Thread: memory granularity of the processor

With C linux pthreads

(1)
How can I enquire which is the memory granularity of the processor ?
I mean what size has one memory access (write or read)?
This info I need to avoid multithread problems
Guess 32bits is the most common?

(2)
How can I control padding of variables to 32bit or 64bit? And padding between fields inside a structure or between array elements? (I mean gcc directives)

Depends on what you mean by "granularity", and for which processor we are talking.

An x86 processor accessing a correctly aligned 32-bit value can perform a read or write operation on such a value without splitting it into parts. Likewise, in 64-bit mode (on x86-64 for example), a 64-bit value is atomic with regards to read/write operations. So, as long as no other thread is (potentially) using the same location, then it's safe to operate on 32 (or 64) bit values in one thread, without worrying about what other threads are doing.

Note however, that a read-modify-write operation where more than one thread may use the same location, would still need some protection to prevent multiple threads accessing a value "halfway" between the read and the write operation, even if the operation itself is one instruction for that particular processor - another cpu(core) doesn't care about operations, as it doesn't actually know what the other processor is doing. To prevent this, you would need (again, on x86) a lock-prefix to ensure that all other potential users back off the bus until the operation is finished - this is, of course bad for performance, as even if the other processors aren't currently using the bus, you'd still have to "ask nicely" and wait for all processors to say "yes, I agree to not use the bus until you're finished". So if this happens often, it will have a negative impact on the performance.

If you are discussing sharing (or, perhaps more importantly, non-sharing) of items between threads, you would need to take into account the size of a cache-line. This varies between different processors, up to 128 bytes for a single cache-line. You shouldn't share cache-lines [that get written to with any frequency] between processors, even if it is technically safe and yields the correct value, because just like with locking the bus, you have to advertize "I'm going to write to cacheline X, can you all please forget you ever heard of that one". If all processors do this often, then you have very poor performance. Note that sharing data that is very rarely (or only once) written, but read often is perfectly fine.

--
Mats

For your 2): http://gnu.huihoo.org/gcc/gcc-3.2.3/...ttributes.html #

[The same applies to other versions, that's just the first link in google that gives the answer].

--
Mats

All elements that are 8, 16, 32 or 64 bit can be accessed as single elements [atomically with respect to read and write operations] in x86. So if you have for example

Code:

struct X
{
    int x;
    int y;
};

Two different threads can (if we ignore cache efficiency) then access x in one thread and y in the other thread, with no conflicts - it makes no difference if the processor is 32 or 64 bit.

If you want to know if the processor is CAPABLE of accessing 64-bit values, then you could check

Code:

sizeof(int *);

. If that comes back as 4, then pointers are 32-bit, and thus the processor is in 32-bit mode.

I forgot to note that floting point, MMX and SSE instructions manage larger "chunks", so the processor could, when using SSE, access 128 bits of data atomically with regards to read and write operations.

--
Mats

Whilst the C standard definition of malloc may not guarantee appropriate alignment for anything, I think you will find that in practice, malloc from glibc and MS visual studio C library will guarantee at least 8 byte alignment, if not 16 byte alignment.

If you want to ensure alignment, then you should write a "aligned malloc" - it's pretty simple (although you have to keep track of a second pointer!):

Code:

void *mallocAligned(size_t size, size_t align, void **freePtr)
{
    *freePtr = malloc(size + align);
    void *p = ((char *)*freePtr) + (int) (*freePtr) + (align-1) & ~(align-1);
    return p;
}

int main()
{
    void *freePtr; 
    char * myptr = mallocAligned(400, 64, &freePtr);
    ... 
    free(freePtr);
    return 0;
}

--
Mats

i am sorry but i do not understand what you mean by "word tearing"

it's pretty tough to understand that function, but I mainly use static data so I might ignore malloc problems

Word tearing is when you access data that is shared within a word.

However, it shouldn't be a problem as long as:
1. You don't mess with the compiler settings for alignment.
2. The processor is an x86 of some sort (AMD, Intel).

--
Mats