Context: on Linux/Debian/Sid x86-64 for my bismon (GPLv3+) software (described here)(GTK 3.24, Glib 2.62, Xorg server, function register_gui_postponed_BM, file gui_GTKBM.c)
Question:
Can g_timeout_add be safely called from some other thread than the main thread? I can easily ensure that call would be serialized (using a pthread mutex) but I cannot guarantee it would be called from the main thread. The threads are Pthreads, not Glib threads.
I found both this and that, and they make me think it is indeed safe.... But I might have understood wrongly.
Yes. It boils down to a call to g_source_attach(), which locks the GMainContext it adds the timeout source to.
Related
I have a multithreaded C++ program in which the main thread creates two tcl interpreters, interp#1 and interp#2. During parallel running, the main thread and one slave thread each try to invoke different cmds through interp#1 and interp#2 seperately. At some point, memory error happens and program crashes.
The log file tells me that some value of kObjv[] for interp#1 is contaminated by that for interp#2.
I also run helgrind to check possible data races and it dumps plenty of data race risks on beneath tcl lib apis, like: Tcl_NewStringObj/TclFreeObj/ResetObjResult/TclNREvalObjv, etc.
It looks like the underlying memory is shared by interpreters from same thread. Is that true? My program links static tcl 8.6 lib, which was installed with thread enabled.
The Tcl library uses thread-bound memory pooling to (hugely!) reduce pressure on global locks, with the consequence that every Tcl interpreter object is also strongly bound to the thread that created it. (This is the Apartment Threading Model, if you're familiar with that.) You cannot safely use a Tcl interpreter from any other thread. If you want to have access to a Tcl interpreter in each thread, each thread should create its own interpreter and use that.
There are a few operations that allow safe inter-thread communication, specifically Tcl_ThreadQueueEvent() and Tcl_ThreadAlert(), which allow you to lodge a message for the other thread to handle when it is ready (every thread with a Tcl interpreter on it has an event queue associated with it inside the Tcl library; this is in the core of the Tcl event notifier engine).
You're recommended to use the Tcl thread package (which should be part of any good Tcl 8.6 installation and is available for older versions too) for inter-thread working in Tcl. Apart from the complexity of getting each side to know what the handle for the other thread is, it's really quite easy to use.
I am trying to embed a ruby1.9 interpreter in a program. I am currently using forkOS in my hruby package, but it seems this only works for ruby 1.8 and 2.x. It looks like 1.9 needs to execute in the primary thread. As a side node, there is no documentation one how to do such a thing, so the only pointer to my current problem is here.
Is there a way to take control of the primary thread to run all my FFI calls ?
Having done some testing and reading of documentation I have come to the following conclusions. The report says all of this is implementation defined so there is no standard way. The module Control.Concurrent states in its documentation that main is a bound thread however it doesn't require that it is the same as the primary OS thread.
Experimentally (at least on Linux 64-bit with GHC 7.8 and 7.10-rc3) the main thread is the OS thread. Given that the main thread is bound it seems there would be no reason for this to be different on other GHC platforms however I cannot test other platforms.
In terms of actually implementing this if you want to program as if ruby was in a different thread you can run most non-ruby stuff in a different thread and communicate with main thread (which talks to the ruby interpreter) via either MVars or TVars. See the comment by #chi for an example of how this is done in gtk.
In terms of a library interface you can have a initialisation function that takes a continuation. Your library hijacks the thread at initialisation and then calls the continuation on another thread. Of course you then need to document to users that it must be called in the main thread.
I m thinking to use Posix robust mutexes to protect shared resource among different processes (on Linux). However there are some doubts about safety in difference scenarios. I have the following questions:
Are robust mutexes implemented in the kernel or in user code?
If latter, what would happen if a process happens to crash while in a call to pthread_mutex_lock or pthread_mutex_unlock and while a shared pthread_mutex datastructure is getting updated?
I understand that if a process locked the mutex and dies, a thread in another process will be awaken and return EOWNERDEAD. However, what would happen if the process dies (in unlikely case) exactly when the pthread_mutex datastructure (in shared memory) is being updated? Will the mutex get corrupted in that case? What would happen to another process that is mapped to the same shared memory if it were to call a pthread_mutex function?
Can the mutex still be recovered in this case?
This question applies to any pthread object with PTHREAD_PROCESS_SHARED attribute. Is it safe to call functions like pthread_mutex_lock, pthread_mutex_unlock, pthread_cond_signal, etc. concurrently on the same object from different processes? Are they thread-safe across different processes?
From the man-page for pthreads:
Over time, two threading implementations have been provided by the
GNU C library on Linux:
LinuxThreads
This is the original Pthreads implementation. Since glibc
2.4, this implementation is no longer supported.
NPTL (Native POSIX Threads Library)
This is the modern Pthreads implementation. By comparison
with LinuxThreads, NPTL provides closer conformance to the
requirements of the POSIX.1 specification and better
performance when creating large numbers of threads. NPTL is
available since glibc 2.3.2, and requires features that are
present in the Linux 2.6 kernel.
Both of these are so-called 1:1 implementations, meaning that each
thread maps to a kernel scheduling entity. Both threading
implementations employ the Linux clone(2) system call. In NPTL,
thread synchronization primitives (mutexes, thread joining, and so
on) are implemented using the Linux futex(2) system call.
And from man futex(7):
In its bare form, a futex is an aligned integer which is touched only
by atomic assembler instructions. Processes can share this integer
using mmap(2), via shared memory segments or because they share
memory space, in which case the application is commonly called
multithreaded.
An additional remark found here:
(In case you’re wondering how they work in shared memory: Futexes are keyed upon their physical address)
Summarizing, Linux decided to implement pthreads on top of their "native" futex primitive, which indeed lives in the user process address space. For shared synchronization primitives, this would be shared memory and the other processes will still be able to see it, after one process dies.
What happens in case of process termination? Ingo Molnar wrote an article called Robust Futexes about just that. The relevant quote:
Robust Futexes
There is one race possible though: since adding to and removing from the
list is done after the futex is acquired by glibc, there is a few
instructions window for the thread (or process) to die there, leaving
the futex hung. To protect against this possibility, userspace (glibc)
also maintains a simple per-thread 'list_op_pending' field, to allow the
kernel to clean up if the thread dies after acquiring the lock, but just
before it could have added itself to the list. Glibc sets this
list_op_pending field before it tries to acquire the futex, and clears
it after the list-add (or list-remove) has finished
Summary
Where this leaves you for other platforms, is open-ended. Suffice it to say that the Linux implementation, at least, has taken great care to meet our common-sense expectation of robustness.
Seeing that other operating systems usually resort to Kernel-based synchronization primitives in the first place, it makes sense to me to assume their implementations would be even more naturally robust.
Following the documentation from here: http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_getrobust.html, it does read that in a fully POSIX compliant OS, shared mutex with the robust flag will behave in the way you'd expect.
The problem obviously is that not all OS are fully POSIX compliant. Not even those claiming to be. Process shared mutexes and in particular robust ones are among those finer points that are often not part of an OS's implementation of POSIX.
In Haskell forkIO creates an unbound (Haskell) thread, and forkOS creates a bound (native) thread. The answer to a previous question here that I had mentioned that Haskell threads are not guaranteed to stay on the same OS thread, which seems to be supported by the documentation for the Control.Concurrent module. My question is, if a running Haskell thread gets swapped to another OS thread, will its ThreadID remain the same?
Yes.
A ThreadId is an abstract type representing a handle to a thread.
This is how you send asynchronous signals to specific threads: with the ThreadId. It does not matter which OS thread is involved, and it is often quite likely that the targeted thread is not bound to any OS thread at all (e.g., it is sleeping).
The existence of "OS threads" is somewhat an implementation detail, although you'll need to manage them if you use the FFI with certain libraries. Otherwise, you can mostly ignore OS threads in your code.
I have GDB attached to a deadlocked application written with pthreads. There are ~10 threads that are all blocked, and I'd like to know which locks are held by which threads. This is possible in WinDbg using SOS.dll; is this possible in GDB?
On at least one flavor of Linux, the C++11 std::mutex has a member called __owner which contains the thread id of the thread that currently has the mutex locked. Using "info threads" in gdb shows the thread numbers used by gdb along with the thread ids (see the "LWP" number), allowing you to switch to that thread ("thread N") and then examine the call stack ("backtrace").
It's not GDB you should be asking about, but rather the specific pthread library and OS you are using.
The pthread library implements mutexes in cooperation with the kernel via some set of system calls. If its implementation of mutexes embeds something to tie the last thread holding the mutex into the mutex data structure, then you can use GDB to get at that information.
It is possible your kernel tracks that information. Under Mac OS X, for example, the collection of GDB scripts bundled with the kernel debugging kit, kgmacros, includes a command showallmtx that will do exactly what you want. The catch: to use it, you have to be debugging the machine's kernel at the time, which means you need to be doing the debugging using a different machine.
Of course, you might have a /dev/kmem device file, which would let you poke around in the kernel's memory and access the necessary data structure, provided you can locate it.
But this all really depends on your system - your pthread library and OS kernel - not on GDB.
You could also try creating a mutex of type PTHREAD_MUTEX_ERRORCHECK; this will cause pthread_mutex_lock() to return EDEADLK instead of deadlocking. You can then break when that occurs and root around in your non-deadlocked process.
GDB could be able to display this information, but they didn't implement this functionality: it requires a cooperation between the debugger and the thread library, though the libthread_db library.
DBX under Solaris -- at least -- (both from Sun, it helps!) implements correctly this feature (look for the Locks part)