Re: [Rd] Thread synchronization [Was: Interrupting C++ code execution]

From: Sean Robert McGuffee <sean.mcguffee_at_gmail.com>
Date: Wed, 27 Apr 2011 15:21:12 -0400


Hi Simon,
That makes a lot of sense to me. I'll start reading about R's event loop signaling. I'm not sure what the best method will be for me to flag the completeness of a threaded process in my case. In abstract it seems that I could get R's event loop to look for any type of flag. I think key for me in this case will be identifying whether a particular file has been completely produced or not. In principle I could put that type of info into the file itself, but I think I could also make a temp file somewhere with it's full path and flag info about it. Then the event loop could look for a particular pattern of temp file names. On the other hand, if I pass in that info when I start the event loop, that might work too. Regarding the external pointer idea, I was thinking about passing an object to R as a return value after launching the thread, and then I might be able to access a pointer inside that object to reference it from my thread. That could be a binary vector or any type of object if I can figure out how to get to it from my thread. Honestly, I don't know much about dynamic referencing of objects from separate threads, but in principle memory is shared in this case. I'll let you know if I come up with anything generic... Please keep me posted on your package. Are any versions of it available yet? It didn't happen to come up on my list of R packages. I haven't necessarily been maintaining an up-to-date version of R though. I don't know if that influences the package list it shows me.
Sean

On 4/26/11 8:51 PM, "Simon Urbanek" <simon.urbanek_at_r-project.org> wrote:

> Sean,
>
> On Apr 26, 2011, at 5:06 PM, Sean Robert McGuffee wrote:
>

>> I've been thinking about how to handle c++ threads that were started via Rcpp
>> calls to some of my c++ libraries from R. My main obstacle is trying to make
>> sure that users don't try to process files that are being generated by a
>> thread before the thread finishes. One thing I am considering is having my
>> threaded code return a class to R that contains a pointer that it remembers.
>> Then maybe I could just change the value at that pointer when my thread
>> finishes. Does that seem like a reasonable approach? I'm not completely sure
>> if this is related to your issue or not, but it might be similar enough to be
>> worth asking...

>
> It depends. For a simple flag it's actually much more simple than that - you
> can create a boolean vector (make sure you preserve it) and just update its
> value when it's done - you don't even need an external pointer for that (if
> your'e careful).
>
> But the slight problem with that approach is rather that you don't have a way
> to tell R about the status change, so essentially you can only poll on the R
> side. A more proper way to deal with this is to use the event loop signaling
> to signal in R that the flag has changed. I'm working on a "threads" package
> that should help with that, but it's not complete yet (you can spawn threads
> from R and you can actually even synchronize them with R [so if the result is
> all you want it's there], but semaphores are not implemented yet --- your
> inquiry should shift it further up on my todo stack ;)).
>
> Cheers,
> Simon


R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Wed 27 Apr 2011 - 19:24:37 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Thu 28 Apr 2011 - 08:21:12 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive