Sponsored Content
Special Forums UNIX and Linux Applications High Performance Computing Memory Barriers for (Ubuntu) Linux (i686) Post 302429949 by gorga on Wednesday 16th of June 2010 08:20:50 AM
Old 06-16-2010
Memory Barriers for (Ubuntu) Linux (i686)

Hi all,

(Hope this is the right forum for this question)

I have some multi-threaded C code (compiled with GCC 4.4.3) which accesses shared variables. Although I've marked those variables with volatile to guard against compiler re-ordering, I'm concerned that processor out-of-order execution may cause my code to fail, and I'm looking for a "low-cost" method of guaranteeing ordering is maintained in my code.

For example, I have something like...

Code:
memset(&task, 0, sizeof(task_t));/* null memory */
task.id.prefix = prefix_id;
task.id.instance = instance_id;
/* write-memorybarrier required here */
task.state = task_ready;

Where I need to ensure that the "task state" is only set to "task_ready" after the previous instructions have been committed. As the "task" is shared between threads, another thread seeing the state as "ready" may try to access its member variables, so it's vital that the tasks "prefix" and "instance" have been updated.

I know this is a common problem and mutexes and semaphores provide in-built memory barriers to address this problem but I'm trying to build a scalable application and I want to avoid their use if possible. I also know GCC provides built-in atomic operations but I see they involve locking the data-bus, and I've heard about system primitives like "smp_wmb()" but I'm not sure how to incorporate these into my "user-space" program as they are platform dependent.

Therefore can anyone provide pointers or advise on how best (in terms of scalability and speed) to guarantee ordering is maintained?

Thanks.
 

4 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

Memory-waste in Ubuntu/Debian?

I have 512 mem on this laptop, though 'top' tells me I only have 380. However, Ubuntu is using 288 mb of memory, when I only have 3 terminals, running lynx, vim(for this file) and (of course) top. Considering it I have lynx running a 600 page txt file, which of course would eat some memory but 300?... (0 Replies)
Discussion started by: riwa
0 Replies

2. Linux

i686, x86 64, ppc

Hi, i am quite new to linux. I am interested in fedora linux distro. Fedora Project I dont know which one to choose, either i686, x86 64 or ppc. I prefer a live cd, coz its easy to use. And what is the difference between "Fedora Desktop Live Media" and "Fedora KDE Live Media". (3 Replies)
Discussion started by: superblacksmith
3 Replies

3. Programming

Getting the total virtual memory for ubuntu in c++

Hi guys , i need to get the total virtual memory in ubuntu but i need to write a C++ code for that, any idea on how to go about doing it? any references? or website that i can refer to ? (6 Replies)
Discussion started by: xiaojesus
6 Replies

4. Ubuntu

XP and Linux (Ubuntu) on same disk, Can I install Ubuntu on not-yet partitioned portion of disk?

My PC (Esprimo, 3 yeas old) has one hard drive having 2 partitions C: (80 GB NTFS, XP) and D: (120 GB NTFS, empty) and and a 200 MB area that yet is not-partitioned. I would like to try Ubuntu and to install Ubuntu on the not-partitioned area . The idea is to have the possibility to run... (7 Replies)
Discussion started by: C.Weidemann
7 Replies
MB(9)							   BSD Kernel Developer's Manual						     MB(9)

NAME
mb, mb_memory, mb_read, mb_write -- memory barriers SYNOPSIS
#include <sys/lock.h> void mb_memory(void); void mb_read(void); void mb_write(void); DESCRIPTION
Many types of processor can execute instructions in a different order than issued by the compiler or assembler. On a uniprocessor system, out of order execution is transparent to the programmer, operating system and applications, as the processor must ensure that it is self con- sistent. On multiprocessor systems, out of order execution can present a problem where locks are not used to guarantee atomicity of access, because loads and stores issued by any given processor can appear on the system bus (and thus appear to other processors) in an unpredictable order. mb_memory(), mb_read(), and mb_write() can be used to control the order in which memory accesses occur, and thus the order in which those accesses become visible to other processors. They can be used to implement ``lockless'' access to data structures where the necessary bar- rier conditions are well understood. Memory barriers can be computationally expensive, as they are considered ``serializing'' operations and may stall further execution until the processor has drained internal buffers and re-synchronized. The memory barrier primitives control only the order of memory access. They provide no guarantee that stores have been flushed to the bus, or that loads have been made from the bus. The memory barrier primitives are guaranteed only to prevent reordering of accesses to main memory. They do not provide any guarantee of ordering when used with device memory (for example, loads or stores to or from a PCI device). To guarantee ordering of access to device mem- ory, the bus_dma(9) and bus_space(9) interfaces should be used. FUNCTIONS
mb_memory() Issue a full memory barrier, ordering all memory accesses. Causes all loads and stores preceding the call to mb_memory() to complete before further memory accesses can be made. mb_read() Issue a read memory barrier, ordering all loads from memory. Causes all loads preceding the call to mb_read() to complete before fur- ther loads can be made. Stores may be reordered ahead of or behind a call to mb_read(). mb_write() Issue a write memory barrier, ordering all stores to memory. Causes all stores preceding the call to mb_write() to complete before further stores can be made. Loads may be reordered ahead of or behind a call to mb_write(). SEE ALSO
__insn_barrier(3), bus_dma(9), bus_space(9), mutex(9), rwlock(9) HISTORY
The memory barrier primitives first appeared in NetBSD 5.0. BSD
January 2, 2011 BSD
All times are GMT -4. The time now is 11:12 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy