From simon.urbanek at r-project.org  Wed Mar 18 18:00:49 2009
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Wed, 18 Mar 2009 13:00:49 -0400
Subject: [Rd] R thread safe
In-Reply-To: <BLU0-SMTP15182A31C747C6DD88103A87990@phx.gbl>
References: <49C0F021.8000108@health.sdu.dk>
	<4BD0BA7D-242B-4D27-A346-745AB8AD088E@r-project.org>
	<4f1819890903180711pcdd2bdbuc4eb15f7af8575f4@mail.gmail.com>
	<83E1179B-072A-42F1-98FB-A06790DA393D@r-project.org>
	<BLU0-SMTP15182A31C747C6DD88103A87990@phx.gbl>
Message-ID: <077CDE8C-BA85-4E3C-846C-0C6BFEB7DFC4@r-project.org>

Kevin,

On Mar 18, 2009, at 12:08 , Kevin Hendricks wrote:

>> I don't think so, because IMHO it makes no sense - you're missing  
>> the main point that R is not thread safe. There are ways to use  
>> threads from within R very cautiously (see Luke's parallelized  
>> vector math operations for R for example). There are many good  
>> methods to use threads in general (pthreads, OpenMP, GCD, ...) and  
>> you can do that as long as you don't use memory allocation in R and  
>> don't call any R functions that may do that (which is most of  
>> them ;)). Making R thread-safe is not really an issue of a  
>> threading toolkit...
>
>
> Memory allocation does not necessarily make a function non-reentrant  
> unless non-shared static variables are involved.  There are a number  
> of thread-safe malloc implementations.    I admit,  I have not  
> looked at the R-internals in a long time.
>

I'm not talking about system-level memory allocation, but at R level  
which uses a garbage collector that is not thread safe and it does  
involve global variables. However, I'm not the right person to comment  
on those issues in detail, but just be assured that several people  
very well versed in the R internals have already looked at this (see  
below).
In addition, there are many more issues in R, because a lot of  
concepts in R just assume sequential operation (graphics devices,  
global options, hooks etc. - see below).


> Based on converting code to be thread safe when I helped port the  
> JDK to Linux, I was amazed about how much code was already reentrant  
> capable and therefore basically thread-safe (or could be made so  
> with small effort - adding a few locks).  In fact the original JVM  
> (jdk 1.0) had a "green-threads" implementation that basically ended  
> up adding wrappers to most of the memory allocation and io system  
> calls system calls to make the whole thing work.
>
> How much of the code itself is now reentrant safe - I noticed that  
> some of the R-internal routines actually used reentrant code and  
> even recursion?  How hard would it be to make the internal object/ 
> memory allocation scheme thread-safe?  As you noted there are many  
> posix threads (pthreads) implmentations out there.
>
> Is there any official effort underway to make R thread-safe?

I know that Duncan TL was looking into this since he did the job for S  
while ago, but I'm not sure how far he got. Luke Tierney has written  
up some thoughts on the issue and despite the document being quite  
dated I think it's still very applicable to today's R:
http://www.stat.uiowa.edu/~luke/R/thrgui/thrgui.pdf

Cheers,
Simon


> If so, are they looking for volunteers.  Would making R fully thread- 
> safe really make that much sense given you can parallelize vector/ 
> matrix operations now (as you noted) which probably provides the  
> most bang for the buck.
>
> Thanks,
>
> Kevin
>
>



[Rd] R thread safe
Simon Urbanek