[igraph] Multi-threading and igraph

[Thomas Gorochowski]

Hi there,

I am attempting to use OpenMP for some statistical sampling. When using igraph functions within a parallel block I have noticed errors occur such as the following:

corrupt finally stack, popping 2 elements when only 1 left
Assertion failed: (no>=0), function IGRAPH_FINALLY_REAL, file error.c, line 126.
Abort trap

I'm assuming that igraph has not been written with multi-threading in mind, however, was wondering if there are any plans to make the library thread-safe in the near future? I'd ideally not like to fork processes as some data is required to be shared and passing that via messages is never much fun!

Thank for a great library and keep up the good work.

Tom.

--
T.E. Gorochowski
University of Bristol, Centre for Complexity Sciences (BCCS)
http://www.chofski.co.uk, tgoroc...@me.com

Try our dynamical network simulator at http://www.netevo.org

_______________________________________________
igraph-help mailing list
igrap...@nongnu.org
http://lists.nongnu.org/mailman/listinfo/igraph-help

[Gábor Csárdi]

Hi Tom,

indeed, the error handling is not thread-safe in igraph. I guess it
would not be too hard to make it thread-safe, but I am not an expert
on this. Could you recommend some good documentation on writing
thread-safe libraries?

Thanks,
Gabor

--
Gabor Csardi <Gabor....@unil.ch>     UNIL DGM

[Tamas Nepusz]

> indeed, the error handling is not thread-safe in igraph. I guess it
> would not be too hard to make it thread-safe

Would it work if we made the finally stack thread-local instead of global?

http://gcc.gnu.org/onlinedocs/gcc-4.5.1/gcc/Thread_002dLocal.html#Thread_002dLocal

--
Tamas

[Thomas Gorochowski]

Hi Gabor,

The following webpage outlines the main points you would need to consider. I'm not familiar with how errors are handled in igraph but one work around if static variables crop up is to use locks to ensure that changes become atomic and therefore safe.

I'm not am expert, but will ask some of the developers in our group to see if they have any other suggestions.

All the best,

Tom

On 29 Oct 2010, at 22:03, Gábor Csárdi <csa...@rmki.kfki.hu> wrote:

> Hi Tom,
>
> indeed, the error handling is not thread-safe in igraph. I guess it
> would not be too hard to make it thread-safe, but I am not an expert
> on this. Could you recommend some good documentation on writing
> thread-safe libraries?
>
> Thanks,
> Gabor
>

> If On Fri, Oct 29, 2010 at 10:22 PM, Thomas Gorochowski

[Gábor Csárdi]

Thanks Tom, but I think you forgot the web page.

Actually, as a solution, I was thinking about assigning a context to
each thread, and this would store the thread-local data. Then at the
beginning of a thread you would need to call an extra function to
allocate this context, but maybe this is not a big deal.

Locking does not really work, at least it is not that simple, because
the threads really need different copies of the error objects, at
least if we don't want one thread failure break the whole program.

So either the context, or the thread-local variables that Tamas
mentioned, would work. I don't like the gcc-specific aspect of the
thread-local thing, but maybe there is a portable solution as well.

Best,
Gabor

On Sat, Oct 30, 2010 at 12:39 AM, Thomas Gorochowski

[Thomas Gorochowski]

Ah yes, sorry about that! Here is the link but it is very brief and only outlines the basics:

http://www.chm.tu-dresden.de/edv/manuals/aix/aixprggd/genprogc/writing_reentrant_thread_safe_code.htm

I've had a look at the tread-local storage and agree that a more portable solution would better if possible.

If I pul up anything further I will let you know,

Tom

[Tamas Nepusz]

> Actually, as a solution, I was thinking about assigning a context to
> each thread, and this would store the thread-local data. Then at the
> beginning of a thread you would need to call an extra function to
> allocate this context, but maybe this is not a big deal.

Yes, but this does not save us from having thread-local variables as the pointer to the current thread context must be stored in a thread-local variable. Or, alternatively, the caller may store it when it calls the function that allocates the context, but then this pointer must be passed on to *every* igraph function that calls IGRAPH_CHECK and IGRAPH_FINALLY. This would change the API of almost every function. By the way, this is the solution chosen by the Java Native Interface (JNI) -- practically one has a JNIEnv* pointer which points to the thread-local context, and JNIEnv* pointers are passed around by pretty much every JNI function.

By the way, wouldn't it be useful now to start a separate mailing list (say, igraph-devel) for development-related questions and leave igraph-help for support questions only?

> I don't like the gcc-specific aspect of the thread-local thing, but maybe there is a portable solution as well.

The Microsoft Visual C++ compiler also has its own solution, e.g.:

__declspec(thread) int variable;

So we could simply go with:

#ifdef __MSVC__
# define IGRAPH_THREAD_LOCAL __declspec(thread)
#elif __GNUC__
# define IGRAPH_THREAD_LOCAL __thread
#else
# define IGRAPH_THREAD_LOCAL
#endif

--
T.

[Gábor Csárdi]

On Sun, Oct 31, 2010 at 2:40 PM, Tamas Nepusz <nta...@gmail.com> wrote:
>> Actually, as a solution, I was thinking about assigning a context to
>> each thread, and this would store the thread-local data. Then at the
>> beginning of a thread you would need to call an extra function to
>> allocate this context, but maybe this is not a big deal.
> Yes, but this does not save us from having thread-local variables

If the context is allocated dynamically by the threads, then you don't
need thread-local storage. I mean, the storage is thread-local, but
you don't need the special mechanisms to handle it. All you need to do
is to call the function to allocate the context at the start of the
thread, and call another one to deallocate it when the thread exists.

Anyway, I'll show you a prototype as soon as I will have enough time
for creating one....then it will turn out whether I'm talking nonsense
or not.

Gabor

> as the pointer to the current thread context must be stored in a thread-local variable. Or, alternatively, the caller may store it when it calls the function that allocates the context, but then this pointer must be passed on to *every* igraph function that calls IGRAPH_CHECK and IGRAPH_FINALLY. This would change the API of almost every function. By the way, this is the solution chosen by the Java Native Interface (JNI) -- practically one has a JNIEnv* pointer which points to the thread-local context, and JNIEnv* pointers are passed around by pretty much every JNI function.
>
> By the way, wouldn't it be useful now to start a separate mailing list (say, igraph-devel) for development-related questions and leave igraph-help for support questions only?
>
>> I don't like the gcc-specific aspect of the thread-local thing, but maybe there is a portable solution as well.
> The Microsoft Visual C++ compiler also has its own solution, e.g.:
>
> __declspec(thread) int variable;
>
> So we could simply go with:
>
> #ifdef __MSVC__
> #  define IGRAPH_THREAD_LOCAL __declspec(thread)
> #elif __GNUC__
> #  define IGRAPH_THREAD_LOCAL __thread
> #else
> #  define IGRAPH_THREAD_LOCAL
> #endif
>
> --
> T.
>
>
> _______________________________________________
> igraph-help mailing list
> igrap...@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/igraph-help
>

--

Gabor Csardi <Gabor....@unil.ch>     UNIL DGM

_______________________________________________