Hi.  Just one last clarifying question on this issue before I dive back in.

Suppose I declared a new Rcpp::List object in my C++ code, and copied the list 
elements from either the SEXP or the original Rcpp::List.  Since the new memory 
is allocated in C++, would I still have the same problem because of the way 
Rcpp allocated the memory?  Or would the copy be thread-safe?

Similarly, what if I were to create an STL container of Rcpp::Lists, and 
operate on each element of the container in parallel?  Same problem?

From your helpful responses, it seems like the best alternative is to 
explicitly copy the contents of each SEXP in the list to a totally non-Rcpp 
object. I'm just wondering if keeping some of the data in the original classes 
might still work.

And finally, since I am still relatively new to C++, are there any standard 
classes that might make more sense than others?  I'm considering an STL vector 
of either Eigen or Armadillo matrices, for example.  Good idea, or bad?

Thanks again,

Michael


On Jul 27, 2011, at 3:55 PM, Dirk Eddelbuettel wrote:

> 
> On 27 July 2011 at 15:04, Michael Braun wrote:
> | It is taking the SEXP as the argument.  If R is the Rcpp::List argument, 
> and i is the index of the parallelized loop, then:
> | 
> | double y = as<double>(R(i));
> | double res = func(y);
> | 
> | does work.  So far, as long as the Rcpp stuff happens in the loop directly 
> (same function), it works.  But if I call another function from the 
> parallelized loop, and do some Rcpp work in that function, that's when I get 
> problems.
> 
> Yes, you cannot 'multithread' R just like that. R is single-threaded and
> (AFAIK) not reentrant.  Just because you'd like it to does not make it
> capable of multi-threaded operations.
> 
> | So while it is great that this works on this simple example, my real-world 
> application is much more complicated (e.g., passing lists of lists), and this 
> kind of workaround doesn't help at all.  But let's get the simple case fixed 
> first.
> 
> You may have to copy your data out of R containers.  Or seperate the R
> processes: if you shield different R sessions, you can have several. See
> Rserve, multicore, Rmpi, ...
> 
> | Are you aware of anyone at all who has had success combining Rcpp and 
> OpenMP?
> 
> If you are careful about your entry and exit from blocks that contain
> multithreaded code, you can use OpenMP -- see the aforementioned example in
> the Rcpp sources.
> 
> Hope this helps,  Dirk
> 
> | On Jul 27, 2011, at 2:55 PM, Davor Cubranic wrote:
> | 
> | > On 2011-07-27, at 10:33 AM, Michael Braun wrote:
> | > 
> | >> I want to avoid making a copy of the entire list (my real-world 
> application might have lots of different elements for each element of the 
> "master" list).  But what works fine is if, within the loop, I do the 
> Rcpp-to-double conversion, and then call a version of the function that takes 
> a double as an argument, instead of the SEXP.  So I think there is something 
> going on with passing the SEXP to func, and then using Rcpp::as to convert 
> the SEXP to double.
> | >> 
> | >> Is this close to what you are asking?
> | > 
> | > Yep. I'm still surprised that Rcpp:as works (I thought it would also take 
> a SEXP as an argument), but if it works, then great.
> | > 
> | > Davor
> | 
> | -------------------------------------------
> | Michael Braun
> | Associate Professor of Management Science (Marketing Group)
> | MIT Sloan School of Management
> | 100 Main St.., E62-535
> | Cambridge, MA 02139
> | bra...@mit.edu
> | 617-253-3436
> | 
> | 
> 
> -- 
> Gauss once played himself in a zero-sum game and won $50.
>                      -- #11 at http://www.gaussfacts.com

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Reply via email to