I want to use std::experimental::barrier in my cpp multi-threaded code. But even if I write a code like this:
#include <iostream>
#include <thread>
#include <experimental/barrier>
int main () {
return 0;
}
the compiler throws an error saying that:
experimental/barrier: No such file or directory
#include <experimental/barrier>
^`
I am using g++ version 6.3.0 on my Ubuntu machine.
This is the command I am trying:
g++ -pthread -std=c++11 top.cpp -o top_new
Currently this library is not yet available.
Maybe this will be usefull:
The GNU C++ Library Manual -> Part III. Extensions -> 30. Concurrency
The file <ext/concurrence.h> contains all the higher-level constructs for playing with threads. In contrast to the atomics layer, the concurrence layer consists largely of types. All types are defined within namespace __gnu_cxx.
...
In addition, there are two macros
_GLIBCXX_READ_MEM_BARRIER
_GLIBCXX_WRITE_MEM_BARRIER
Which expand to the appropriate write and read barrier required by the host hardware and operating system.
Related
QUESTION
How can I run different instances of the same program in different cores at 100%?
CONTEXT
I am running a C++11 code in an iMac Pro (2017) with OS High Sierra 10.13.6. The corresponding executable is called 'bayesian_estimation'.
When I run one instance of this program, one of the cores is doing that task at 100%, as you can see here:
If I run more instances, the CPU% of each of them goes down. But most of the cores remain idle! Why are not they being used? See, for example, what happens when 3 'bayesian_estimation' processes are running:
Or when I execute 7:
Ideally in the last picture, I would like to have 7 cores completely busy, each of them running one 'bayesian_estimation' process.
EDIT 1
I proceed to give more information that might help to identify the problem. I compiled my code as follows:
g++ -std=c++11 -Wall -g bayesian_estimation.cpp -o bayesian_estimation -O2 -larmadillo
And all libraries and packages that I have used are the following:
#include <iostream> // Standard input and output functions.
#include <iomanip> // Manipulate stream input and output functions.
#include <armadillo> // Load Armadillo library.
#include <sys/stat.h> // To obtain information from files (e.g., S_ISDIR).
#include <dirent.h> // Format of directory entries.
#include <vector> // To deal with vectors.
I identified the origin of the bottleneck that #bolov mentions in the comments. It arises due to the use of arma_rng::set_seed_random() in the code to generate random numbers with the Armadillo library. If I remove that line of the code, the problem is gone.
A question going deeper into this issue and providing with a reproducible example is posted here.
I wanted to practice with standard C++ threads instead of UNIX ones, but soon encountered a problem, whenever I write std::thread CLion underlines it with red and says Can't resolve namespace member 'thread'. I checked my CMake file it's set for C++11. I reinstalled the latest version of MinGW (6.3.0) and ticked a box with G++ compiler. I have been told by my friend that he uses Cygwin and everything works. But is it still possible to make it work with MinGW?
#include <iostream>
#include <thread>
#define BUFFER_SIZE 3
#define PROD_NUM 3
#define CONS_NUM 2
void produce(){
//production
}
void consume(){
//consumption
}
int main() {
std::cout << "Hello, World!" << std::endl;
int i,j;
std::thread producer(produce);
std::thread consumer (consume);
return 0;
}
The code itself has literally nothing
EDIT
in thread library there is
#pragma GCC system_header
#if __cplusplus < 201103L
# include <bits/c++0x_warning.h>
#else
#include <chrono>
#include <functional>
#include <memory>
#include <cerrno>
#include <bits/functexcept.h>
#include <bits/functional_hash.h>
#include <bits/gthr.h>
#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1)
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
/**
* #defgroup threads Threads
* #ingroup concurrency
*
* Classes for thread support.
* #{
*/
/// thread
class thread
{
public:
// Abstract base class for types that wrap arbitrary functors to be
// invoked in the new thread of execution.
struct _State
{
virtual ~_State();
virtual void _M_run() = 0;
};
can you make sure if the library is available in the CLion toolchain? For example Cygwin does have the include.
CLion shows things red when it can't link codes with the library.
It is possibly a host environment variable error. Make sure your CMakeLists.txt is working and your environment variables, standard library linkage is correct as well as your compiler setup.
Compiler version and and standard libraries compatible. (e.g. you are using a cross-compiler (RasPi, Android) but environment vars shows host library etc. will make it fail)
Check this relevant post, it may help.
C++11 std::threads vs posix threads
Ok, so I finally solved the problem. I installed Cygwin and in CLion Settings I manually linked C/C++ compilers (for some reason CLion was unable to auto-detect them). Cleared all and re-indexed the project. Now it shows no errors and code compiles.
Regarding MinGW, I read on cplusplus.com some posts regarding the issue but they were about previous versions of MinGW and it was said that they finally fixed it, however I tell: No, they didn't. Here there is a nice repository and its README file suggests that thread of win32 rely on gthreads, however i found gthread file in my libraries everything seemed ok... so still need to investigate the issue. Write your ideas and experience here if you know more.
As for now solution is Cygwin, use it instead of MinGW.
P.S. Thanks #KillzoneKid for links
I'm very new in Ubuntu and programming C++ on Ubuntu using Geany.
The problem I have here is that:
the classes i want to iclude to my project will receive an error,
I type,
#include <vector>
the error given here is,
fatal error: vector: No such file or directory
also I cannot use namespace std,
typing using namespace std returns the following error,
error: unknown type name 'using'
Here is the code:
#include <stdio.h> //no problem here
#include "stdlib.h" //no problem here
#include <vector> //this is a problem (lets say it returns error 1)
using namespace std; //this is a problem (lets say it returns error 2)
int main(int argc, char **argv)
{
return 0;
}
This sounds like you are using the wrong compiler to compile your C++ code. For example, by invoking gcc test.cpp the C++ file is actually compiled as C and you receive errors such as the one you posted - there is no vector header in C and there is also no using keyword.
If you are using gcc, the correct way to invoke the compiler to compile C++ is via the g++ symlink, i.e. g++ test.cpp
If you are using clang, the executable is called clang++ instead.
Both compilers support the -x parameter to manually change the language to C++, although in that case you also have to specify that the compiler needs to link your files with the C++ standard library. For example: gcc -x c++ test.cpp -lstdc++
I have 2 program I wrote on my windows computer using Visual Studio 2013. They run fine and work perfectly on my computer, but when I brought them over to my school account that is on a Linux machine, a problem arose. They compile and 1 ran, but the other did not. The one that did not run gave me an error:
.../lib/compat/libstdc++.so.6: version CXXABI_1.3.2 required by...
I have been doing research and I can't seem to find out what in my program would be using libstdc++.so.6, I'm not even really sure what it is or does. Since I am on a student account I can't go installing it using sudo, and it is a homework so I can't submit it using my own libraries.
Any Idea on what my program might be using that would require libstdc++.so.6?
I have 3 files: main.cpp, LinkedList.cpp and LinkedList.h.
I think it might be in main.cpp because I think it stems from a library I am including and main.cpp is the only one that uses outside libraries. Here is the list of libraries it uses:
#include <iomanip>
#include <stdio.h>
#include <fstream>
#include <ctype.h>
#include <string>
#include <iostream>
#include <vector>
#include <sstream>
#include <bitset>
#include <algorithm>
#include "LinkedList.h"
Thanks in advance!
You are trying to run a program linked against one version of the libraries under another set. That should work fine as long as the library versions aren't too far apart. In your case, the difference between libraries is just too large.
GCC (C++ in particular) has changed quite a bit lately, some programs that used to compile and run fine now blow up or don't compile at all (due to language changes, compiler bugs accepting broken code, ...), and the library ABI has also changed. Your best bet is to carry source code around, and make sure you got compatible language versions on both ends. If that is inconvenient, a solution is to make sure you have the same compiler (and other environment) at both places. The easiest way to get this is to install the same distribution and version.
First you can't remove the dependencies of libstdc++.so.6, because it's a standard C++ library.
To solve your problem you have to check whether your libstdc++.so have the right version
strings /usr/lib64/libstdc++.so.6|grep GXXABI_1.3.1
if there have no matching version, you will have 2 methods like these:
update your gcc on your school's linux OS
yum intsall gcc
download a matching libstdc++.so from this website:
download gcc || download matching libstdc++
then replace the libstdc++.so to /usr/lib64/libstdc++.so.6.*
SOLUTION
I went through a few steps to find my solution. Originally I could compile my program but could not run it.
1) My first step to solve the issue was to change my method of compiling. Originally I compiled my program with the following: g++ main.cpp LinkedList.cpp -o output. I changed it to: g++ -static main.cpp LinkedList.cpp -o output which allowed me to compile and run. This worked but static is a method to dynamically link libraries. This prevents linking with the shared libraries. This is not a good solution because it takes a lot longer and increases the file size of the executable, so I wanted to improve.
2) The second thing I did was remove using namespace std. Yes, I cheated and used it. So I went through my program and added std:: to the appropriate places.
3) The last thing I did was clean up my code. I was using a lot of libraries because my program was a large and complicated program. I was using all of the libraries I had listed in my original post. I went through my code and anywhere I was using a function from a library I would try and write my own code that would do the same thing which would result in my program not depending on those libraries. I was able to replicate a decent amount of these dependent foreign functions with my own which added lot of code, but it allowing me to remove some of these includes. My list of includes is now:
#include <fstream>
#include <string>
#include <iostream>
#include <vector>
#include <algorithm>
#include "LinkedList.h"
#include <math.h>
I am not sure exactly which step resolved my issue, but now I can compile with my preferred method, g++ main.cpp LinkedList.cpp -o output, and my program runs fine.
I hope this helps someone.
I have a C++ library with a particular function that returns a boost::any, whose value type is a particular enum defined in a different included library. This normally works fine.
But when I link to my library dynamically from a Matlab mex file, typeid(the_enum_t) seems to be different for the things made in my library and those made in the caller, in that it doesn't compare ==. Since I'm actually using flann, whose version of boost::any performs a check based on type_info::==, this makes everything break. Static linking works fine, but that's kind of a pain here, and I'd really rather have it work either way.
I thought type_info::== was supposed to work consistently across library boundaries. Does this have to do with how Matlab dynamically loads libraries from mex?
Here's some code to reproduce this (also available in easy-to-download form, with a makefile, in this gist).
First, a stand-in for the library that defines the enum (flann):
namespace library {
enum the_enum_t { el_one, el_two, el_three };
}
Now a proxy for my library, stubby.hpp:
#include <boost/any.hpp>
#include "the_enum.hpp"
boost::any the_function();
And its implementation stubby.cpp:
#include "stubby.hpp"
boost::any the_function() {
return boost::any(library::el_two);
}
Finally, test code test.cpp, which is compiled with -DNO_MEX for a standalone and not for a mex file:
#include "stubby.hpp"
#include <boost/any.hpp>
#ifdef NO_MEX
#include <cstdio>
using std::printf;
int main() {
#else
#include "mex.h"
void mexFunction(int nlhs, mxArray **plhs, int nrhs, const mxArray **prsh) {
#endif
boost::any val_any = the_function();
printf("%s (equal: %d)\n",
val_any.type().name(),
val_any.type() == typeid(library::the_enum_t));
}
I get the expected output
N5flann17flann_algorithm_tE (equal: 1)
from each of
$ g++ -o test{,.cpp} -DNO_MEX libstubby.a && ./test
$ g++ -o test{_s,.cpp} -DNO_MEX libstubby.so && ./test_s
$ ln -sf test{,_s}.cpp && mex test_s.cpp libstubby.a && matlab -r test
But dynamically linking a mex file doesn't work:
$ mex test.cpp libstubby.so && matlab -r test
N5flann17flann_algorithm_tE (equal: 0)
I see this same behavior on
Matlab R2011b and R2011a, OSX 10.7, Apple gcc 4.2.1
Matlab R2011b, CentOS 5.7, gcc 4.1.2
Matlab R2010a, Ubuntu 11.04, gcc 4.4.5
The weird thing is that I could've sworn it worked a few months ago, but maybe I just did a bad job of testing.
Obviously I can get around this by static linking. But why is this happening? Does it have something to do with the way Matlab loads mex files and their libraries?
Boost has a workaround for this issue; see https://svn.boost.org/trac/boost/ticket/754
It's possible that boost is failing to enable the workaround. Try passing compiler flag -DBOOST_AUX_ANY_TYPE_ID_NAME per the patch on that ticket.