igraph-help
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [igraph] Multi-threading and igraph


From: Gábor Csárdi
Subject: Re: [igraph] Multi-threading and igraph
Date: Sun, 31 Oct 2010 17:17:58 +0100

On Sun, Oct 31, 2010 at 2:40 PM, Tamas Nepusz <address@hidden> 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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/igraph-help
>



-- 
Gabor Csardi <address@hidden>     UNIL DGM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]