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
iv_task(3)						    ivykis programmer's manual							iv_task(3)

NAME
iv_task_register, iv_task_unregister, iv_task_registered - deal with ivykis tasks SYNOPSIS
#include <iv.h> struct iv_task { void *cookie; void (*handler)(void *); }; void IV_TASK_INIT(struct iv_task *task); void iv_task_register(struct iv_task *task); void iv_task_unregister(struct iv_task *task); int iv_task_registered(struct iv_task *task); DESCRIPTION
The functions iv_task_register and iv_task_unregister register, respectively unregister, a task with the current thread's ivykis event loop. iv_task_registered on a task returns true if that task is currently registered with ivykis. A task is like a timer, but with an immediate timeout. When a task is registered, unless it is unregistered again first, the callback function specified by ->handler is guaranteed to be called once, in the thread that the task was registered in, some time after control returns to the ivykis main loop but before ivykis will sleep for more events, with ->cookie as its first and sole argument. When this hap- pens, the task is transparently unregistered. Tasks are mainly used for scheduling code for execution where it is not appropriate to directly run that code in the calling context (for example, because the current context might be run as a callback function where the caller expects certain conditions to remain invariant after the callback completes). The application is allowed to change the ->cookie and ->handler members at any time. A given struct iv_task can only be registered in one thread at a time, and a task can only be unregistered in the thread that it was regis- tered from. There is no limit on the number of tasks registered at once. See iv_examples(3) for programming examples. SEE ALSO
ivykis(3), iv_examples(3) ivykis 2010-08-15 iv_task(3)
All times are GMT -4. The time now is 11:45 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy