I have created a new thread in my program with CreaThread() function which is present in windows.h and I compiled with with this command gcc myprogram.c but when i started my program it seem that the thread was not started why?i thought that gcc doesn't multithreading can any one help me
gcc supports multi-threading. The support is not limited to ability to call CreateThread function, there are most importantly C memory model, C atomic operations, C thread support library
Related
Does JIT uses GCC or any other native compiler as its backend to generate its native code?
Also, is there any relation between the C2, C1 of JIT and O1, O2, O3 optimization flags of GCC?
Thanks for the answer.
The JVM is a standalone operating system process that interprets byte codes (in Java, .class type files) and runs them. That may mean it runs code that stays entirely inside of the JVM (perhaps string concatenation for example) or calls the underlying O/S to take care of the code it is running (for example, reading a file). Each JVM will implement this it's own way but it does not create a file in another programming language to then be handled by that environment.
GCC converts C and C++ code to the assembly / machine code appropriate for the processor it is built for (i.e. x86_64, Arm64, etc.) Generally the output from GCC is meant for a single type of processor and operating system. There are exceptions - some compilers can build "fat" binaries that contain code targeted at multiple processors.
So, because of that, the JVM doesn't understand or care about the GCC optimization flags. While the JVM itself is likely compiled with a compiler like GCC once it's built it no longer has any interaction with the GCC (or other) compiler.
Despite pthread_mutex, would mutex (#include <mutex>) make pthread safe using C++11?
Please find down an example:
// Creating Server thread
pthread_create(&server_thread, NULL,Server,NULL);
// Creating Client thread
pthread_create(&client_thread, NULL, Client,NULL);
// Wait until client_thread exits
pthread_join( client_thread, NULL);
both Server, and Client call foo().
mutex mut;
void foo (){
mut.lock();
CRITICAL_WRITE();
mut.unlock();
}
It is implementation specific. The C++11 standard libraries I know about (e.g. libstdc++ in GCC 4.9, and probably also libc++ from Clang/LLVM) are practically built above the existing pthreads(7) library on Linux.
Someone could in principle build some C++11 standard library on Linux directly using system calls (e.g. futex(2) -mixed with hand-written assembly code- for mutual exclusion locks), but I know none such C++11 library.
The threads are built on Linux in pthreads above the low-level clone(2) syscall.
So you don't have a formal guarantee, but in practice you are today quite safe (on Linux)
In a project that I have been asked to revise, there is a segment of code that is tantamount to just generating a set of assembly instructions, writing them to a file, and then compiling it with the gcc compiler.
My question is, is there any way to link in a library that would do this work for me via an exposed API call? I need 1-1 equivalence to the following command:
gcc -m32 -c -o objfile generated_asm.asm -masm=intel
You cannot do exactly that. You might fork the GCC compilation command. It is probably operating system specific, I'm supposing you are on Linux (or some other POSIX system).
However, there are alternatives:
using asmjit to generate x86 machine code in memory
using tinycc and its libtcc library (which can compile a string containing C or asm code; beware, the compiled machine code is slow since unoptimized)
using a JIT library like libjit, or LLVM, or GNU lightning
coding in a metaprogramming language like Common Lisp (e.g. SBCL) or MetaOcaml
Also, you could simply fork a GCC compilation of some generated C file genfoo.c into a shared object (gcc -Wall -O -fPIC genfoo.c -shared -o genfoo.so) then dynamically loading with dlopen the ./genfoo.so file (see also this)
PS. Next GCC 5.0 release will have a JIT library (libgccjit).
Generally, no, because Unix insisted we think of everything as text strings (including command lines). And we all accepted Unix.
Technically GCC is just giant subroutine with a big parameter list.
The fact that you get to it though a text string is a stupid design decision we all made by dumping Multics and/or LISP machines. On these systems, subroutines (even big ones) are all called natively, and thus really compose.
With Multics, the compiler is (well was, Multics is pretty dead) a subroutine you can call. (Yes, there was a command line interface that could also make that call, so people could invoke it).
I'm installing mingw-w64 on Windows and there are two options: win32 threads and posix threads. I know what is the difference between win32 threads and pthreads but I don't understand what is the difference between these two options. I doubt that if I will choose posix threads it will prevent me from calling WinAPI functions like CreateThread.
It seems that this option specify which threading API will be used by some program or library, but by what? By GCC, libstdc++ or by something else?
I found this:
Whats the difference between thread_posixs and thread_win32 in gcc port of windows?
In short, for this version of mingw, the threads-posix release will use the posix API and allow the use of std::thread, and the threads-win32 will use the win32 API, and disable the std::thread part of the standard.
Ok, if I will select win32 threads then std::thread will be unavailable but win32 threads will still be used. But used by what?
GCC comes with a compiler runtime library (libgcc) which it uses for (among other things) providing a low-level OS abstraction for multithreading related functionality in the languages it supports. The most relevant example is libstdc++'s C++11 <thread>, <mutex>, and <future>, which do not have a complete implementation when GCC is built with its internal Win32 threading model. MinGW-w64 provides a winpthreads (a pthreads implementation on top of the Win32 multithreading API) which GCC can then link in to enable all the fancy features.
I must stress this option does not forbid you to write any code you want (it has absolutely NO influence on what API you can call in your code). It only reflects what GCC's runtime libraries (libgcc/libstdc++/...) use for their functionality. The caveat quoted by #James has nothing to do with GCC's internal threading model, but rather with Microsoft's CRT implementation.
To summarize:
posix: enable C++11/C11 multithreading features. Makes libgcc depend on libwinpthreads, so that even if you don't directly call pthreads API, you'll be distributing the winpthreads DLL. There's nothing wrong with distributing one more DLL with your application.
win32: No C++11 multithreading features.
Neither have influence on any user code calling Win32 APIs or pthreads APIs. You can always use both.
Parts of the GCC runtime (the exception handling, in particular) are dependent on the threading model being used. So, if you're using the version of the runtime that was built with POSIX threads, but decide to create threads in your own code with the Win32 APIs, you're likely to have problems at some point.
Even if you're using the Win32 threading version of the runtime you probably shouldn't be calling the Win32 APIs directly. Quoting from the MinGW FAQ:
As MinGW uses the standard Microsoft C runtime library which comes with Windows, you should be careful and use the correct function to generate a new thread. In particular, the CreateThread function will not setup the stack correctly for the C runtime library. You should use _beginthreadex instead, which is (almost) completely compatible with CreateThread.
Note that it is now possible to use some of C++11 std::thread in the win32 threading mode. These header-only adapters worked out of the box for me:
https://github.com/meganz/mingw-std-threads
From the revision history it looks like there is some recent attempt to make this a part of the mingw64 runtime.
#rubenvb answer is fully correct, use the mingw posix compiler if you want to use std::thread, std::mutex, etc. For everybody who is using CMake, here is an example:
set(CMAKE_CXX_STANDARD 17) # or 20 if you want..
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(THREADS_PREFER_PTHREAD_FLAG ON)
set(TOOLCHAIN_PREFIX x86_64-w64-mingw32)
set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}-gcc-posix)
set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PREFIX}-g++-posix)
set(CMAKE_RC_COMPILER ${TOOLCHAIN_PREFIX}-windres)
set(CMAKE_FIND_ROOT_PATH
/usr/${TOOLCHAIN_PREFIX}
)
Ideal for cross-compiling Linux apps to Windows.
Hint: For people who are using GTK3 and want to cross-compile their GTK application to Windows. You maybe want to download the Mingw Windows GTK bundle, downloaded and packaged from msys2.org so you don't need to: https://gitlab.melroy.org/melroy/gtk-3-bundle-for-windows
I have many structs (classes) and standalone functions that I like to compile separately and then link to the CUDA kernel, but I am getting the External calls are not supported error while compiling (not linking) the kernel. nvcc forces to always use inline functions from the kernel. This is very frustrating!! If somebody have figured out a way to achieve incremental compilation, please share.
Also see the following thread on NVIDIA forums.
http://forums.nvidia.com/index.php?s=&showtopic=103256&view=findpost&p=1009242
Currently you cannot call device functions from the GPU in CUDA, which is why they are inlined.
Fermi hardware supports device functions without inlining.
Ok, it can now be done with CUDA 5.