Sponsored Content
Special Forums UNIX and Linux Applications High Performance Computing Memory Barriers for (Ubuntu) Linux (i686) Post 302430449 by gorga on Thursday 17th of June 2010 03:48:05 PM
Old 06-17-2010
Quote:
Originally Posted by Corona688
Small world, how so? Smilie
Noting your help on the Programming forum too!

Quote:
I think you're overreacting... Any memory I/O monopolizes the bus*, LOCK just guarantees one instruction gets two ops in a row.
Are you suggesting then, that if I used such an instruction relatively frequently (say once in a loop of maybe a 100 execution statements, per core), I shouldn't notice a significant drop in throughput of the application?

Quote:
I'm not sure LOCK XCGH even forces a real memory fetch anymore(might be simple to test, try to get back to you on that.)
You'd expect that each core accessing the XCHG variable though would have to get the value from memory though as soon as it accessed it, otherwise what use would CMPXCHG be? Not sure about this area to be honest, (but I read that these atomic operations do create a memory barrier so a core cannot execute instructions either side of said barrier out of order).

Quote:
Lastly, if you're doing no mutexing, what are you doing instead -- polling? That's not going to be more efficient, untold amounts of CPU will be expended on what amounts to a while(1) loop.
What I'm building is a thread-pool with n pthreads equal to the number of cores (so I am using pthreads). The pthreads continually execute a list of "lightweight tasks". The user can create tasks and send "messages" between them. (If you've ever used Erlang, something similar to the abstraction provided there but in my case using C).

The pthreads occasionally check the "value" of a task "state", when they reach that task in the queue, therefore if the "state" isn't "ready" they simply move on to the next task (hence the pthread has more work to do and isn't polling continuously). You see what this means, as long as a pthread "eventually" discovers a task is "ready" that's okay, even if it's not asap. It seems like a lock would be unnecessary here then, but a pthread shouldn't detect that the task state is "ready" before its other data members have been updated (hence the need for a memory barrier).

If using these atomic operations isn't going to impact throughput, then great they solve the problem, but even that seems like overkill when I only need to ensure that a handful of statements are executed in a certain order.
 

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
import-bug-from-debian(1)				      General Commands Manual					 import-bug-from-debian(1)

NAME
import-bug-from-debian - Import bugs from Debian's BTS, and file them against Ubuntu in LP. SYNOPSIS
import-bug-from-debian [options] bug... import-bug-from-debian -h DESCRIPTION
import-bug-from-debian clones bugs from Debian's BTS into Launchpad. Each bug listed on the command line has its initial report re-filed against the same source package in Ubuntu. The Ubuntu bug is linked back to its Debian counterpart. Each bug may be provided either as a bug number or URL. OPTIONS
-b, --browserless Don't open the bug in a browser at the end. -h, --help Display a help message and exit. -l INSTANCE, --lpinstance=INSTANCE Use the specified instance of Launchpad (e.g. "staging"), instead of the default of "production". -p PACKAGE, --package=PACKAGE Launchpad package to file bug against, if not the same source package name as Debian. Useful for importing removal bugs filed against ftp.debian.org. --no-conf Do not read any configuration files, or configuration from environment variables. ENVIRONMENT
All of the CONFIGURATION VARIABLES below are also supported as environment variables. Variables in the environment take precedence to those in configuration files. CONFIGURATION VARIABLES
The following variables can be set in the environment or in ubuntu-dev-tools(5) configuration files. In each case, the script-specific variable takes precedence over the package-wide variable. IMPORT_BUG_FROM_DEBIAN_LPINSTANCE, UBUNTUTOOLS_LPINSTANCE The default value for --lpinstance. SEE ALSO
ubuntu-dev-tools(5) AUTHORS
import-bug-from-debian was written by James Westby <james.westby@ubuntu.com>, and this manual page was written by Stefano Rivera <ste- fanor@ubuntu.com>. Both are released under the terms of the GNU General Public License, version 2. ubuntu-dev-tools September 21 2010 import-bug-from-debian(1)
All times are GMT -4. The time now is 04:54 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy