I'm aware that Julia's threads are "green threads". The issue of thread safety still remains; if one thread is suspended in a critical region, another can enter that region. Storing handles in global data structures and incrementing global variables are such actions, and I'm not 100% sure that the respective region in serialize.jl are yield-free, even without my info output. I was surprised to see that I/O causes task switches -- maybe something else (hashing? dictionaries? creating new lambdas in C?) also causes task switches?
gdb points to memory allocation routines in libc, called from gc.c or array.c. I assume that something overwrites memory, destroying libc malloc's data structures, leading to a crash later. -erik On Sun, Sep 21, 2014 at 5:26 AM, Tim Holy <[email protected]> wrote: > Hi Erik, > > First, one comment: tasks are not "true" (kernel) threads. Currently a julia > process is single-threaded. Tasks are better considered as a form of > cooperative multitasking. > > Yes, I've also found that I/O causes task switching. I don't personally know a > great way around this. One option would presumably be to have some form of > message queue; I am pretty sure that push!ing a new message on it---as long as > you don't need to touch I/O to create the message---would not cause a switch. > You can also use time() and other markers to indicate the status of control > flow. > > I haven't been reading things carefully enough to know whether there's any > history behind this, but if you haven't said so already...what does gdb (or > equivalent) say about the segfault? > > --Tim > > On Saturday, September 20, 2014 08:24:59 PM Erik Schnetter wrote: >> I am trying to track down a segfault in a Julia application. Currently I am >> zooming in on "deserialize", as avoiding calling it seems to reliably cure >> the problem, while calling it (even if not using the result) seems to >> reliably trigger the segfault. >> >> I am using many threads (tasks), and deserialize is called concurrently. Is >> this safe? I've been bitten in the past by this; e.g. I've accidentally >> added an "info" statement into a sequence of statements that needs to be >> atomic, and I/O apparently switches threads. Is there a list of >> known-to-be-safe or known-to-be-unsafe functions? Is deserialization >> thread-safe in this respect? >> >> I am in particular deserializing function calls and lambda expressions, and >> I see global variables ("lambda_numbers", "known_lambda_data"). Are the >> respective data structures (WeakKeyDict and Dict) thread-safe? >> >> Is there a locking mechanism in Julia? This would temporarily only allow a >> single thread (task) to run, aborting with an error if this thread becomes >> unrunnable. In other words, calling "yield" when holding a lock would be a >> no-op. >> >> -erik > -- Erik Schnetter <[email protected]> http://www.perimeterinstitute.ca/personal/eschnetter/
