Search Results

Search found 413 results on 17 pages for 'atomic clocks'.

Page 1/17 | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

• Build-Essentials installation failing

  - by Brickman

  I am having trouble accessing the several critical header files that show to be a part of the build process. The "Ubuntu Software Center" shows "Build Essentials" as installed: Next I did the following two commands, which did not improve the problem: ~$ sudo apt-get install build-essential [sudo] password for: Reading package lists... Done Building dependency tree Reading state information... Done build-essential is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. :~$ sudo apt-get install -f Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. :~$ Dump of headers after installation attempts. > /usr/include/boost/interprocess/detail/atomic.hpp > /usr/include/boost/interprocess/smart_ptr/detail/sp_counted_base_atomic.hpp > /usr/include/qt4/Qt/qatomic.h /usr/include/qt4/Qt/qbasicatomic.h > /usr/include/qt4/QtCore/qatomic.h > /usr/include/qt4/QtCore/qbasicatomic.h > /usr/share/doc/git-annex/html/bugs/git_annex_unlock_is_not_atomic.html > /usr/src/linux-headers-3.11.0-15/arch/alpha/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/arc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/arm/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/arm64/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/avr32/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/blackfin/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/cris/include/arch-v10/arch/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/cris/include/arch-v32/arch/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/cris/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/frv/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/h8300/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/hexagon/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/ia64/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/m32r/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/m68k/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/metag/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/microblaze/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/mips/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/mn10300/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/parisc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/powerpc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/s390/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/score/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/sh/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/sparc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/tile/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/x86/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/arch/xtensa/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-15/include/asm-generic/atomic.h > /usr/src/linux-headers-3.11.0-15/include/asm-generic/bitops/atomic.h > /usr/src/linux-headers-3.11.0-15/include/asm-generic/bitops/ext2-atomic.h > /usr/src/linux-headers-3.11.0-15/include/asm-generic/bitops/non-atomic.h > /usr/src/linux-headers-3.11.0-15/include/linux/atomic.h > /usr/src/linux-headers-3.11.0-15-generic/include/linux/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/alpha/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/arc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/arm/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/arm64/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/avr32/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/blackfin/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/cris/include/arch-v10/arch/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/cris/include/arch-v32/arch/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/cris/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/frv/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/h8300/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/hexagon/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/ia64/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/m32r/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/m68k/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/metag/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/microblaze/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/mips/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/mn10300/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/parisc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/powerpc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/s390/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/score/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/sh/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/sparc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/tile/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/x86/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/arch/xtensa/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-17/include/asm-generic/atomic.h > /usr/src/linux-headers-3.11.0-17/include/asm-generic/bitops/atomic.h > /usr/src/linux-headers-3.11.0-17/include/asm-generic/bitops/ext2-atomic.h > /usr/src/linux-headers-3.11.0-17/include/asm-generic/bitops/non-atomic.h > /usr/src/linux-headers-3.11.0-17/include/linux/atomic.h > /usr/src/linux-headers-3.11.0-17-generic/include/linux/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/alpha/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/arc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/arm/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/arm64/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/avr32/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/blackfin/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/cris/include/arch-v10/arch/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/cris/include/arch-v32/arch/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/cris/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/frv/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/h8300/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/hexagon/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/ia64/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/m32r/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/m68k/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/metag/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/microblaze/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/mips/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/mn10300/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/parisc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/powerpc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/s390/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/score/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/sh/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/sparc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/tile/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/x86/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/arch/xtensa/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-18/include/asm-generic/atomic.h > /usr/src/linux-headers-3.11.0-18/include/asm-generic/bitops/atomic.h > /usr/src/linux-headers-3.11.0-18/include/asm-generic/bitops/ext2-atomic.h > /usr/src/linux-headers-3.11.0-18/include/asm-generic/bitops/non-atomic.h > /usr/src/linux-headers-3.11.0-18/include/linux/atomic.h > /usr/src/linux-headers-3.11.0-18-generic/include/linux/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/alpha/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/arc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/arm/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/arm64/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/avr32/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/blackfin/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/cris/include/arch-v10/arch/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/cris/include/arch-v32/arch/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/cris/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/frv/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/h8300/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/hexagon/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/ia64/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/m32r/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/m68k/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/metag/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/microblaze/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/mips/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/mn10300/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/parisc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/powerpc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/s390/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/score/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/sh/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/sparc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/tile/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/x86/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/arch/xtensa/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-19/include/asm-generic/atomic.h > /usr/src/linux-headers-3.11.0-19/include/asm-generic/bitops/atomic.h > /usr/src/linux-headers-3.11.0-19/include/asm-generic/bitops/ext2-atomic.h > /usr/src/linux-headers-3.11.0-19/include/asm-generic/bitops/non-atomic.h > /usr/src/linux-headers-3.11.0-19/include/linux/atomic.h > /usr/src/linux-headers-3.11.0-19-generic/include/linux/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/alpha/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/arc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/arm/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/arm64/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/avr32/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/blackfin/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/cris/include/arch-v10/arch/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/cris/include/arch-v32/arch/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/cris/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/frv/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/h8300/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/hexagon/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/ia64/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/m32r/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/m68k/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/metag/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/microblaze/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/mips/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/mn10300/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/parisc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/powerpc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/s390/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/score/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/sh/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/sparc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/tile/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/x86/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/arch/xtensa/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-20/include/asm-generic/atomic.h > /usr/src/linux-headers-3.11.0-20/include/asm-generic/bitops/atomic.h > /usr/src/linux-headers-3.11.0-20/include/asm-generic/bitops/ext2-atomic.h > /usr/src/linux-headers-3.11.0-20/include/asm-generic/bitops/non-atomic.h > /usr/src/linux-headers-3.11.0-20/include/linux/atomic.h > /usr/src/linux-headers-3.11.0-20-generic/include/linux/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/alpha/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/arc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/arm/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/arm64/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/avr32/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/blackfin/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/cris/include/arch-v10/arch/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/cris/include/arch-v32/arch/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/cris/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/frv/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/h8300/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/hexagon/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/ia64/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/m32r/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/m68k/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/metag/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/microblaze/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/mips/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/mn10300/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/parisc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/powerpc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/s390/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/score/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/sh/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/sparc/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/tile/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/x86/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/arch/xtensa/include/asm/atomic.h > /usr/src/linux-headers-3.11.0-22/include/asm-generic/atomic.h > /usr/src/linux-headers-3.11.0-22/include/asm-generic/bitops/atomic.h > /usr/src/linux-headers-3.11.0-22/include/asm-generic/bitops/ext2-atomic.h > /usr/src/linux-headers-3.11.0-22/include/asm-generic/bitops/non-atomic.h > /usr/src/linux-headers-3.11.0-22/include/linux/atomic.h > /usr/src/linux-headers-3.11.0-22-generic/include/linux/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/alpha/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/arc/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/arm/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/arm64/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/avr32/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/blackfin/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/cris/include/arch-v10/arch/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/cris/include/arch-v32/arch/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/cris/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/frv/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/hexagon/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/ia64/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/m32r/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/m68k/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/metag/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/microblaze/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/mips/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/mn10300/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/parisc/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/powerpc/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/s390/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/score/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/sh/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/sparc/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/tile/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/x86/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/arch/xtensa/include/asm/atomic.h > /usr/src/linux-headers-3.14.4-031404/include/asm-generic/atomic.h > /usr/src/linux-headers-3.14.4-031404/include/asm-generic/bitops/atomic.h > /usr/src/linux-headers-3.14.4-031404/include/asm-generic/bitops/ext2-atomic.h > /usr/src/linux-headers-3.14.4-031404/include/asm-generic/bitops/non-atomic.h > /usr/src/linux-headers-3.14.4-031404/include/linux/atomic.h > /usr/src/linux-headers-3.14.4-031404-generic/include/linux/atomic.h > /usr/src/linux-headers-3.14.4-031404-lowlatency/include/linux/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/alpha/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/arc/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/arm/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/arm64/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/avr32/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/blackfin/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/cris/include/arch-v10/arch/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/cris/include/arch-v32/arch/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/cris/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/frv/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/h8300/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/hexagon/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/ia64/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/m32r/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/m68k/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/metag/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/microblaze/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/mips/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/mn10300/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/parisc/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/powerpc/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/s390/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/score/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/sh/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/sparc/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/tile/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/x86/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/arch/xtensa/include/asm/atomic.h > /usr/src/linux-lts-saucy-3.11.0/include/asm-generic/atomic.h > /usr/src/linux-lts-saucy-3.11.0/include/asm-generic/bitops/atomic.h > /usr/src/linux-lts-saucy-3.11.0/include/asm-generic/bitops/ext2-atomic.h > /usr/src/linux-lts-saucy-3.11.0/include/asm-generic/bitops/non-atomic.h > /usr/src/linux-lts-saucy-3.11.0/include/linux/atomic.h > /usr/src/linux-lts-saucy-3.11.0/ubuntu/lttng/lib/ringbuffer/vatomic.h > /usr/src/linux-lts-saucy-3.11.0/ubuntu/lttng/wrapper/ringbuffer/vatomic.h > /usr/src/linux-lts-saucy-3.11.0/ubuntu/lttng-modules/lib/ringbuffer/vatomic.h > /usr/src/linux-lts-saucy-3.11.0/ubuntu/lttng-modules/wrapper/ringbuffer/vatomic.h Yes, I know there are multiple headers of the same type here, but they are different versions. Version "linux-headers-3.14.4-031404" shows to be the latest. Ubuntu shows "Nothing needed to be installed." However, the following C/C++ headers files show to be missing for Eclipse and QT4. #include <linux/version.h> #include <linux/module.h> #include <linux/socket.h> #include <linux/miscdevice.h> #include <linux/list.h> #include <linux/vmalloc.h> #include <linux/slab.h> #include <linux/init.h> #include <asm/uaccess.h> #include <asm/atomic.h> #include <linux/delay.h> #include <linux/usb.h> This problem appears on my 32-bit version of Ubuntu and on both of my 64-bit versions. What I am doing wrong?

  Read the article

• How do NTP Servers Manage to Stay so Accurate?

  - by Akemi Iwaya

  Many of us have had the occasional problem with our computers and other devices retaining accurate time settings, but a quick sync with an NTP server makes all well again. But if our own devices can lose accuracy, how do NTP servers manage to stay so accurate? Today’s Question & Answer session comes to us courtesy of SuperUser—a subdivision of Stack Exchange, a community-driven grouping of Q&A web sites. Photo courtesy of LEOL30 (Flickr). The Question SuperUser reader Frank Thornton wants to know how NTP servers are able to remain so accurate: I have noticed that on my servers and other machines, the clocks always drift so that they have to sync up to remain accurate. How do the NTP server clocks keep from drifting and always remain so accurate? How do the NTP servers manage to remain so accurate? The Answer SuperUser contributor Michael Kjorling has the answer for us: NTP servers rely on highly accurate clocks for precision timekeeping. A common time source for central NTP servers are atomic clocks, or GPS receivers (remember that GPS satellites have atomic clocks onboard). These clocks are defined as accurate since they provide a highly exact time reference. There is nothing magical about GPS or atomic clocks that make them tell you exactly what time it is. Because of how atomic clocks work, they are simply very good at, having once been told what time it is, keeping accurate time (since the second is defined in terms of atomic effects). In fact, it is worth noting that GPS time is distinct from the UTC that we are more used to seeing. These atomic clocks are in turn synchronized against International Atomic Time or TAI in order to not only accurately tell the passage of time, but also the time. Once you have an exact time on one system connected to a network like the Internet, it is a matter of protocol engineering enabling transfer of precise times between hosts over an unreliable network. In this regard a Stratum 2 (or farther from the actual time source) NTP server is no different from your desktop system syncing against a set of NTP servers. By the time you have a few accurate times (as obtained from NTP servers or elsewhere) and know the rate of advancement of your local clock (which is easy to determine), you can calculate your local clock’s drift rate relative to the “believed accurate” passage of time. Once locked in, this value can then be used to continuously adjust the local clock to make it report values very close to the accurate passage of time, even if the local real-time clock itself is highly inaccurate. As long as your local clock is not highly erratic, this should allow keeping accurate time for some time even if your upstream time source becomes unavailable for any reason. Some NTP client implementations (probably most ntpd daemon or system service implementations) do this, and others (like ntpd’s companion ntpdate which simply sets the clock once) do not. This is commonly referred to as a drift file because it persistently stores a measure of clock drift, but strictly speaking it does not have to be stored as a specific file on disk. In NTP, Stratum 0 is by definition an accurate time source. Stratum 1 is a system that uses a Stratum 0 time source as its time source (and is thus slightly less accurate than the Stratum 0 time source). Stratum 2 again is slightly less accurate than Stratum 1 because it is syncing its time against the Stratum 1 source and so on. In practice, this loss of accuracy is so small that it is completely negligible in all but the most extreme of cases. Have something to add to the explanation? Sound off in the comments. Want to read more answers from other tech-savvy Stack Exchange users? Check out the full discussion thread here.

  Read the article

• Atomic swap in GNU C++

  - by Steve

  I want to verify that my understanding is correct. This kind of thing is tricky so I'm almost sure I am missing something. I have a program consisting of a real-time thread and a non-real-time thread. I want the non-RT thread to be able to swap a pointer to memory that is used by the RT thread. From the docs, my understanding is that this can be accomplished in g++ with: // global Data *rt_data; Data *swap_data(Data *new_data) { #ifdef __GNUC__ // Atomic pointer swap. Data *old_d = __sync_lock_test_and_set(&rt_data, new_data); #else // Non-atomic, cross your fingers. Data *old_d = rt_data; rt_data = new_data; #endif return old_d; } This is the only place in the program (other than initial setup) where rt_data is modified. When rt_data is used in the real-time context, it is copied to a local pointer. For old_d, later on when it is sure that the old memory is not used, it will be freed in the non-RT thread. Is this correct? Do I need volatile anywhere? Are there other synchronization primitives I should be calling? By the way I am doing this in C++, although I'm interested in whether the answer differs for C. Thanks ahead of time.

  Read the article

• The Clocks on USACO

  - by philip

  I submitted my code for a question on USACO titled "The Clocks". This is the link to the question: http://ace.delos.com/usacoprob2?a=wj7UqN4l7zk&S=clocks This is the output: Compiling... Compile: OK Executing... Test 1: TEST OK [0.173 secs, 13928 KB] Test 2: TEST OK [0.130 secs, 13928 KB] Test 3: TEST OK [0.583 secs, 13928 KB] Test 4: TEST OK [0.965 secs, 13928 KB] Run 5: Execution error: Your program (`clocks') used more than the allotted runtime of 1 seconds (it ended or was stopped at 1.584 seconds) when presented with test case 5. It used 13928 KB of memory. ------ Data for Run 5 ------ 6 12 12 12 12 12 12 12 12 ---------------------------- Your program printed data to stdout. Here is the data: ------------------- time:_0.40928452 ------------------- Test 5: RUNTIME 1.5841 (13928 KB) I wrote my program so that it will print out the time taken (in seconds) for the program to complete before it exits. As can be seen, it took 0.40928452 seconds before exiting. So how the heck did the runtime end up to be 1.584 seconds? What should I do about it? This is the code if it helps: import java.io.; import java.util.; class clocks { public static void main(String[] args) throws IOException { long start = System.nanoTime(); // Use BufferedReader rather than RandomAccessFile; it's much faster BufferedReader f = new BufferedReader(new FileReader("clocks.in")); // input file name goes above PrintWriter out = new PrintWriter(new BufferedWriter(new FileWriter("clocks.out"))); // Use StringTokenizer vs. readLine/split -- lots faster int[] clock = new int[9]; for (int i = 0; i < 3; i++) { StringTokenizer st = new StringTokenizer(f.readLine()); // Get line, break into tokens clock[i * 3] = Integer.parseInt(st.nextToken()); clock[i * 3 + 1] = Integer.parseInt(st.nextToken()); clock[i * 3 + 2] = Integer.parseInt(st.nextToken()); } ArrayList validCombination = new ArrayList();; for (int i = 1; true; i++) { ArrayList combination = getPossibleCombinations(i); for (int j = 0; j < combination.size(); j++) { if (tryCombination(clock, (int[]) combination.get(j))) { validCombination.add(combination.get(j)); } } if (validCombination.size() > 0) { break; } } int [] min = (int[])validCombination.get(0); if (validCombination.size() > 1){ String minS = ""; for (int i=0; i<min.length; i++) minS += min[i]; for (int i=1; i<validCombination.size(); i++){ String tempS = ""; int [] temp = (int[])validCombination.get(i); for (int j=0; j<temp.length; j++) tempS += temp[j]; if (tempS.compareTo(minS) < 0){ minS = tempS; min = temp; } } } for (int i=0; i<min.length-1; i++) out.print(min[i] + " "); out.println(min[min.length-1]); out.close(); // close the output file long end = System.nanoTime(); System.out.println("time: " + (end-start)/1000000000.0); System.exit(0); // don't omit this! } static boolean tryCombination(int[] clock, int[] steps) { int[] temp = Arrays.copyOf(clock, clock.length); for (int i = 0; i < steps.length; i++) transform(temp, steps[i]); for (int i=0; i<temp.length; i++) if (temp[i] != 12) return false; return true; } static void transform(int[] clock, int n) { if (n == 1) { int[] clocksToChange = {0, 1, 3, 4}; add3(clock, clocksToChange); } else if (n == 2) { int[] clocksToChange = {0, 1, 2}; add3(clock, clocksToChange); } else if (n == 3) { int[] clocksToChange = {1, 2, 4, 5}; add3(clock, clocksToChange); } else if (n == 4) { int[] clocksToChange = {0, 3, 6}; add3(clock, clocksToChange); } else if (n == 5) { int[] clocksToChange = {1, 3, 4, 5, 7}; add3(clock, clocksToChange); } else if (n == 6) { int[] clocksToChange = {2, 5, 8}; add3(clock, clocksToChange); } else if (n == 7) { int[] clocksToChange = {3, 4, 6, 7}; add3(clock, clocksToChange); } else if (n == 8) { int[] clocksToChange = {6, 7, 8}; add3(clock, clocksToChange); } else if (n == 9) { int[] clocksToChange = {4, 5, 7, 8}; add3(clock, clocksToChange); } } static void add3(int[] clock, int[] position) { for (int i = 0; i < position.length; i++) { if (clock[position[i]] != 12) { clock[position[i]] += 3; } else { clock[position[i]] = 3; } } } static ArrayList getPossibleCombinations(int size) { ArrayList l = new ArrayList(); int[] current = new int[size]; for (int i = 0; i < current.length; i++) { current[i] = 1; } int[] end = new int[size]; for (int i = 0; i < end.length; i++) { end[i] = 9; } l.add(Arrays.copyOf(current, size)); while (!Arrays.equals(current, end)) { incrementWithoutRepetition(current, current.length - 1); l.add(Arrays.copyOf(current, size)); } int [][] combination = new int[l.size()][size]; for (int i=0; i<l.size(); i++) combination[i] = (int[])l.get(i); return l; } static int incrementWithoutRepetition(int[] n, int index) { if (n[index] != 9) { n[index]++; return n[index]; } else { n[index] = incrementWithoutRepetition(n, index - 1); return n[index]; } } static void p(int[] n) { for (int i = 0; i < n.length; i++) { System.out.print(n[i] + " "); } System.out.println(""); } }

  Read the article

• e-mail appearing in light blue on atomic browser

  - by Eduardo Montenegro

  Hi, all, I made an html page, and only for Atomic Browser (on iPhone) when I put an e-mail in a page like a "contact us", the e-mail appears in light blue (only in atomic). Anyone have a suggestion for this issue? Regards, Eduardo

  Read the article

• Are +=, |=, &= etc atomic?

  - by SF.

  Are the "modify" operators like +=, |=, &= etc atomic? I know ++ is atomic (if you perform x++; in two different threads "simultaneously", you will always end up with x increased by 2, as opposed to x=x+1 with optimization switched off.) What I wonder is whether variable |= constant, and the likes are thread-safe or do I have to protect them with a mutex? (...or is it CPU-dependent? In this case, how is it on ARM?)

  Read the article

• Is writing a reference atomic on 64bit VMs

  - by Steffen Heil

  Hi The java memory model mandates that writing a int is atomic: That is, if you write a value to it (consisting of 4 bytes) in one thread and read it in another, you will get all bytes or none, but never 2 new bytes and 2 old bytes or such. This is not guaranteed for long. Here, writing 0x1122334455667788 to a variable holding 0 before could result in another thread reading 0x112233440000000 or 0x0000000055667788. Now the specification does not mandate object references to be either int or long-sized. For type safety reasons I suspect they are guaranteed to be written atomiacally, but on a 64bit VM these references could be very well 64bit values (merely memory addresses). No here are my question: Are there any memory model specs covering this (that I haven't found)? Are long-writes suspect to be atomic on 64bit VMs? Are VMs forced to map references to 32bit? Regards, Steffen

  Read the article

• Visual C++ 2010 atomic types support?

  - by Electro

  Does VC++ 2010 have support for C++0x's portable atomic type template?

  Read the article

• Atomic UPSERT in SQL Server 2005

  - by rabidpebble

  What is the correct pattern for doing an atomic "UPSERT" (UPDATE where exists, INSERT otherwise) in SQL Server 2005? I see a lot of code on SO (e.g. see http://stackoverflow.com/questions/639854/tsql-check-if-a-row-exists-otherwise-insert) with the following two-part pattern: UPDATE ... FROM ... WHERE <condition> -- race condition risk here IF @@ROWCOUNT = 0 INSERT ... or IF (SELECT COUNT(*) FROM ... WHERE <condition>) = 0 -- race condition risk here INSERT ... ELSE UPDATE ... where will be an evaluation of natural keys. None of the above approaches seem to deal well with concurrency. If I cannot have two rows with the same natural key, it seems like all of the above risk inserting rows with the same natural keys in race condition scenarios. I have been using the following approach but I'm surprised not to see it anywhere in people's responses so I'm wondering what is wrong with it: INSERT INTO <table> SELECT <natural keys>, <other stuff...> FROM <table> WHERE NOT EXISTS -- race condition risk here? ( SELECT 1 FROM <table> WHERE <natural keys> ) UPDATE ... WHERE <natural keys> (Note: I'm assuming that rows will not be deleted from this table. Although it would be nice to discuss how to handle the case where they can be deleted -- are transactions the only option? Which level of isolation?) Is this atomic? I can't locate where this would be documented in SQL Server documentation.

  Read the article

• Atomic Instructions and Variable Update visibility

  - by dsimcha

  On most common platforms (the most important being x86; I understand that some platforms have extremely difficult memory models that provide almost no guarantees useful for multithreading, but I don't care about rare counter-examples), is the following code safe? Thread 1: someVariable = doStuff(); atomicSet(stuffDoneFlag, 1); Thread 2: while(!atomicRead(stuffDoneFlag)) {} // Wait for stuffDoneFlag to be set. doMoreStuff(someVariable); Assuming standard, reasonable implementations of atomic ops: Is Thread 1's assignment to someVariable guaranteed to complete before atomicSet() is called? Is Thread 2 guaranteed to see the assignment to someVariable before calling doMoreStuff() provided it reads stuffDoneFlag atomically? Edits: The implementation of atomic ops I'm using contains the x86 LOCK instruction in each operation, if that helps. Assume stuffDoneFlag is properly cleared somehow. How isn't important. This is a very simplified example. I created it this way so that you wouldn't have to understand the whole context of the problem to answer it. I know it's not efficient.

  Read the article

• "pseudo-atomic" operations in C++

  - by dan

  So I'm aware that nothing is atomic in C++. But I'm trying to figure out if there are any "pseudo-atomic" assumptions I can make. The reason is that I want to avoid using mutexes in some simple situations where I only need very weak guarantees. 1) Suppose I have globally defined volatile bool b, which initially I set true. Then I launch a thread which executes a loop while(b) doSomething(); Meanwhile, in another thread, I execute b=true. Can I assume that the first thread will continue to execute? In other words, if b starts out as true, and the first thread checks the value of b at the same time as the second thread assigns b=true, can I assume that the first thread will read the value of b as true? Or is it possible that at some intermediate point of the assignment b=true, the value of b might be read as false? 2) Now suppose that b is initially false. Then the first thread executes bool b1=b; bool b2=b; if(b1 && !b2) bad(); while the second thread executes b=true. Can I assume that bad() never gets called? 3) What about an int or other builtin types: suppose I have volatile int i, which is initially (say) 7, and then I assign i=7. Can I assume that, at any time during this operation, from any thread, the value of i will be equal to 7? 4) I have volatile int i=7, and then I execute i++ from some thread, and all other threads only read the value of i. Can I assume that i never has any value, in any thread, except for either 7 or 8? 5) I have volatile int i, from one thread I execute i=7, and from another I execute i=8. Afterwards, is i guaranteed to be either 7 or 8 (or whatever two values I have chosen to assign)?

  Read the article

• atomic operation cost

  - by osgx

  Hello What is the cost of the atomic operation? How much cycles does it consume? Will it pause other processors on SMP or NUMA, or will it block memory accesses? Will it flush reorder buffer in out-of-order CPU? What effects will be on the cache? Thanks.

  Read the article

• sequentially-consistent atomic load on x86

  - by axe

  Hello all, I'm interested in sequentially-consistent load operation on x86. As far as I see from assembler listing, generated by compiler it is implemented as a plain load on x86, however plain loads as far as I know guaranteed to have acquire semantics, while plain stores are guaranteed to have release. Sequentially-consistent store is implemented as locked xchg, while load as plain load. That sounds strange to me, could you please explain this in details? added Just found in internet, that sequentially-consistent atomic load could be done as simple mov as long as store is done with locked xchg, but there was no prove and no links to documentation. Do you know where can I read about that? Thanks in advance.

  Read the article

• Slow draw on some apps and dynamic clocks not working properly with ATI/AMD proprietary drivers

  - by Rakeka

  I've recently purchased a new computer (around July 2010) and I've been having some problems with proprietary video drivers on Linux. The hardware is: Video: ATI/AMD Radeon HD 5870 (XFX HD-587X-ZNFC); Motherboard: Asus P7P55D-E Deluxe; Processor: Intel i5 750; Memory: Kingston Hyperx KHX1600C8D3K2/4GX (2x - 8GB Total); Power Supply: XFX P1-750B-CAG9; There are no overclocks, not even the memories (they are at 1333mhz due processor memory controller limitation). The operational system is a homebrew Linux distribution with the following software: Architecture: x86_64 (multilib) Kernel: 2.6.35.10 Xorg: 7.5 Window Manager: wmii-3.9.2 Video Driver: ATI/AMD Catalyst 10.12 There are no desktop effects programs like compiz fusion or beryl. The problems: With ATI/AMD proprietary driver, some applications are with slow draw/redraw, and, the same applications make the driver to increase the card clocks to maximum (0% gpu activity, only the clocks are increased). I dunno exactly how to describe the slow draw but I'll list some applications and symptoms. xterm Flickers a lot when drawing continuous output; When I'm in a workspace with fullscreen xterm, The gpu load stays at 12% in idle, and, with smaller xterm, smaller GPU load. "aticonfig --odgc" output: Default Adapter - ATI Radeon HD 5800 Series Core (MHz) Memory (MHz) Current Clocks : 157 300 Current Peak : 850 1200 Configurable Peak Range : [600-900] [900-1300] GPU load : 12% "aticonfig --pplib-cmd 'get activity'" output: Current Activity is Core Clock: 157MHZ Memory Clock: 300MHZ VDDC: 950 Activity: 12 percent Performance Level: 0 Bus Speed: 5000 Bus Lanes: 16 Maximum Bus Lanes: 16 More examples: mplayer time info flickers on terminal; "find /" flickers a lot (It takes some time to stop with control-c. But, If I change the workspace or put some window upon it, just after the control-c, it stops instantly); "cat somefile" if the file is big (Xorg.0.log for example) it takes some time to display; vim and less (ex: find / | less) don't have much problems, just a little flicker when scrolling; mplayer (no gui) Slow reproduction and seek with -vo x11; Tearing with -vo xv; Time info flickers on terminal (xterm consequence); gvim A little slow draw when scrolling with page up/page down; Firefox Slow draw/redraw on some pages like www.boadica.com.br and sometimes on www.youtube.com with flash enable (never noticed on many pages); Corruptions when informative yellow boxes are showing and scroll the page (an gray box appears at the same place of the informative box); "Wallpaper" After minimizing a fullscreen window or changing to an empty workspace it takes some time to redraw wallpaper. "Video Card" The core and memory clocks are increased with the events described above and on other situations like change workspace (even without wallpaper), minimize, maximize or move a window; Idle clocks: Core: 157mhz, Memory: 300mhz Full clocks: Core: 850mhz, Memory: 1200mhz xpdf Painful slow scrolling; display (from ImageMagick) Slow menus and sometimes slow image redraw; Programs that I use and are apparently without problems: gimp; pidgin; mplayer (-vo gl, gl2); blender; unigine heaven (better fps than on Windows); doom3; tibia; penumbra overture; amnesia the dark descent (wine); diablo 2 (wine); No problems on Windows (Windows 7 Ultimate 64bit). And special note to this: Full desktop effects from Debian and Ubuntu gnome appearance cpanel don't cause ANY problems, even the core and memory clocks don't increase when change workspace, minimize, maximize or move a window. What I've tested: Unsuccessful tests: Tested all drivers versions since 10.6 (released approximately when I've installed the first slackware in this PC); Tested other video card - ATI/AMD Radeon HD 5570 (XFX HD-557X-ZHF2); Tested some options on xorg.conf and that I've found googling (some of these options are commented on my xorg.conf. I'll send the links at the end of post); Tested some patches like 107_fedora_dont_fill_bg_none.patch and xserver-xorg-backclear.patch from Arch Linux Catalyst page (https://wiki.archlinux.org/index.php/ATI_Catalyst); Tested other distros and software versions: Tested XORG-7.6 on my own distribution; Tested Debian Squeeze (testing - from 2010-12-20); Tested Ubuntu Marverick (10.10); Tested Slackware 13.1; Distros info: Architecture: i386 Debian and Ubuntu with all default software (kernel, gnome, xorg, drivers); Slackware with Catalyst from AMD page and default window managers like: fvwm, xfce, and my own build of wmii; Successful tests: Tested other video card (only on my homebrew distro) - NVIDIA Geforce 7300GS with driver 260.19.29; That didn't shown the slow draw problems, but that card is a bit obsolete, so, dunno if that lacks features like the dynamic clocks. I don't dispose of other video cards like nvidia g/gt/gts/gtx 200~400~500 or Radeon HD 3000/4000/6000 to make more tests. Tested other hardware: Video: ATI/AMD Radeon HD 5570 (XFX HD-557X-ZHF2); Motherboard: Intel DG31PR; Processor: Core 2 Duo E6750; Software for that hardware: Fresh install of same distros (except for the mine) with same program versions; That video card (HD 5570) were full time at the maximum clocks (something like 500/750, don't remember) in all the operational systems (Windows XP and Windows 7 too), but it didn't shown the same problems that I have here. I've googled a lot about common problems with ATI/AMD proprietary drivers for Linux and didn't find similar problems, except by the Firefox corruptions, that the solutions were to disable ATI Direct2DAccel and use XAA. With XAA the problems persists and the other applications like pidgin and rest of Firefox showed the same problems of slow draw/redraw. Open source Drivers: With open source drivers (xf86-video-ati-6.13.2) I hadn't the same slow draw problems, but, had other problems, that, for now, make it no viable solution. I'll not discuss it here because this is another line of problems and will confuse everything. If it happens to be the only solution, I'll make another thread to discuss it. Logs and Configs: kernel .config dmesg xorg package list xorg.conf Xorg.0.log

  Read the article

• Clarification of atomic memory access for different OSs

  - by murrekatt

  I'm currently porting a Windows C++ library to MacOS as a hobby project as a learning experience. I stumbled across some code using the Win Interlocked* functions and thus I've been trying to read up on the subject in general. Reading related questions here in SO, I understand there are different ways to do these operations depending on the OS. Interlocked* in Windows, OSAtomic* in MacOS and I also found that compilers have builtin (intrinsic) operations for this. After reading gcc builtin atomic memory access, I'm left wondering what is the difference between intrinsic and the OSAtomic* or Interlocked* ones? I mean, can I not choose between OSAtomic* or gcc builtin if I'm on MacOS when I use gcc? The same if I'd be on Windows using gcc. I also read that on Windows Interlocked* come as both inline and intrinsic versions. What to consider when choosing between intrinsic or inline? In general, are there multiple options on OSs what to use? Or is this again "it depends"? If so, what does it depend on? Thanks!

  Read the article

• AtomicSwap instead of AtomicCompareAndSwap ?

  - by anon

  I know that on MacOSX / PosiX systems, there is atomic-compare-and-swap for C/C++ code via g++. However, I don't need the compare -- I just want to atomically swap two values. Is there an atomic swap operation available? [Everythign I can find is atomic_compare_and_swap ... and I just want to do the swap, without comparing]. Thanks!

  Read the article

• Atomic operations on several transactionless external systems

  - by simendsjo

  Say you have an application connecting 3 different external systems. You need to update something in all 3. In case of a failure, you need to roll back the operations. This is not a hard thing to implement, but say operation 3 fails, and when rolling back, the rollback for operation 1 fails! Now the first external system is in an invalid state... I'm thinking a possible solution is to shut down the application and forcing a manual fix of the external system, but then again... It might already have used this information (and perhaps that's why it failed), or we might not have sufficient access. Or it might not even be a good way to rollback the action! Are there some good ways of handling such cases? EDIT: Some application details.. It's a multi user web application. Most of the work is done with scheduled jobs (through Quartz.Net), so most operations is run in it's own thread. Some user actions should trigger jobs that update several systems though. The external systems are somewhat unstable. I Was thinking of changing the application to use the Command and Unit Of Work pattern

  Read the article

• c++11 atomic ordering: extended total order memory_order_seq_cst for locks

  - by itaj

  There's this note in c++11 29.3-p3: [ Note: Although it is not explicitly required that S include locks, it can always be extended to an order that does include lock and unlock operations, since the ordering between those is already included in the "happens before" ordering. - end note ] What does it mean by "always"? I can understand that any certain implementation can be designed to support such an extended S. But in some general implementation that wasn't designed for it, I don't see that S can be extended so. I had sent this question to comp.std.c++ but got no answers there. http://groups.google.com/group/comp.std.c++/browse_frm/thread/5242fa70d0594d1b#

  Read the article

• Session state provider and atomic operations

  - by vtortola

  Hi, I've been thinking about this and it is blowing my mind... How does a session state provider properly works internally? I mean, I tried to write a custom session state provider based on Azure Tables or Blobs, but quickly I realized that because there is no way to ensure an atomic operation or establish a lock, race conditions are suitable to happen when several web servers do operation on that shared information. I know that there is a SQL Server Session State Provider (SQLS-SSP) and people is happy with it, so I guess that it's using some kind of transaction isolation level in order to accomplish some degree of concurrent safety, like checking is the data is lock (a simple column), locking it if not and returning the data in an atomic operation, but is that so? what does happen if the data is lock? does it returns an error? block the call for a while? returns it in read-only fashion? Cloud computing paradigms could be somehow new, but webfarms have been here for a while, so as I'm pretty new on it... do you recommend any good lecture about the topic? Thanks.

  Read the article

• Why is the volatile qualifier used through out std::atomic?

  - by Caspin

  From what I've read from Herb Sutter and others you would think that volatile and concurrent programming were completely orthogonal concepts, at least as far as C/C++ are concerned. However, in GCC c++0x extension all of std::atomic's member functions have the volatile qualifier. The same is true in Anthony Williams's implementation of std::atomic. So what's deal, do my atomic<> variables need be volatile or not?

  Read the article

• How atomic is a SELECT INTO?

  - by leo.pasta

  Last week I got an interesting situation that prompted me to challenge a long standing assumption. I always thought that a SELECT INTO was an atomic statement, i.e. it would either complete successfully or the table would not be created. So I got very surprised when, after a “select into” query was chosen as a deadlock victim, the next execution (as the app would handle the deadlock and retry) would fail with: Msg 2714, Level 16, State 6, Line 1 There is already an object named '#test' in the database. The only hypothesis we could come up was that the “create table” part of the statement was committed independently from the actual “insert”. We can confirm that by capturing the “Transaction Log” event on Profiler (filtering by SPID0). The result is that when we run: SELECT * INTO #results FROM master.sys.objects we get the following output on Profiler: It is easy to see the two independent transactions. Although this behaviour was a surprise to me, it is very easy to workaround it if you feel the need (as we did in this case). You can either change it into independent “CREATE TABLE / INSERT SELECT” or you can enclose the SELECT INTO in an explicit transaction: SET XACT_ABORT ON BEGIN TRANSACTION SELECT * INTO #results FROM master.sys.objects COMMIT

  Read the article

• Is OSCompareAndSwap is immune to ABA problem like CMPXCHG8B?

  - by Viet

  Is OSCompareAndSwap is immune to ABA problem like CMPXCHG8B?

  Read the article

• Are the atomic builtins provided by gcc actually translated into the example code, or is that just f

  - by Jared P

  So I was reading http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html, and came across this: type __sync_and_and_fetch (type *ptr, type value, ...) type __sync_xor_and_fetch (type *ptr, type value, ...) type __sync_nand_and_fetch (type *ptr, type value, ...) These builtins perform the operation suggested by the name, and return the new value. That is, { *ptr op= value; return *ptr; } { *ptr = ~*ptr & value; return *ptr; } // nand Is this code literal? or is it just to explain what gcc is doing atomically using c-like syntax? And if this is the direct translation, can someone explain how it is atomic?

  Read the article

• In C is "i+=1;" atomic?

  - by Crazy Chenz

  In C, is i+=1; atomic?

  Read the article

• Processing a list of atomic operations, allowing for interruptions

  - by JDB

  I'm looking for a design pattern that addresses the following situation: There exists a list of tasks that must be processed. Tasks may be added at any time. Each task is wholly independent from all other tasks. The order in which tasks are processed has no effect on the overall system or on the tasks themselves. Every task must be processed once and only once. The "main" process which launches the task processors may start and stop without warning. When stopped, the "main" process loses all in-memory data. Obviously this is going to involve some state, but are there any design patterns which discuss where and how to maintain that state? Are there any relevant anti-patterns? Named patterns are especially helpful so that we can discuss this topic with other organizations without having to describe the entire problem domain.

  Read the article

1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >