GU_Detail and Multithreading

[Stalkerx777]

Hello. According to documentation, writing to GU_Detail is not thread safe. I have a couple of questions about that.

 

1. If i need to protect my data, i can use locks (UT_Lock). Cant it be used to write to gdp? For example (pseudo code):

void doWork(GU_Detail *gdp)
{
    {
       UT_Lock::Scope lock();
       // Write to gdp here ?
    }
}

2. I'd like to understand what GU_DetailHandle class is, and why and when should i use it? This class also offer some locking methods such as writeLock() and a helper class GU_DetailHandleAutoWriteLock. I guess the later is what i need? 

 

3. To be clear, what i'm trying to do is to generate a hundreds of new GU_Detail instances in different threads, and then merge them down into one detail. Something similar to Duplicate SOP.

 

Consider a following code single thread code:

// get geometry from second input
const GU_Detail *pattern = inputGeo(1);
GU_Detail *copy;
for (int i(0); i < 100; i++);
{
    copy = new GU_Detail(pattern);
    // Call functions to modify copy geometry
    gdp->merge(*copy);

}

I want the for loop to be executed in parallel. I'm planing to use THREADED_METHOD2 macros. I'm curious, how GU_DetailHandle can be used in this situation to synchronise writing to detail? OR maybe i should go with another strategy, for example threads produces GU_Details, and main thread performs merging?

 

I'd like to hear any ideas and your experience guys.

[edward]

I think that page is saying it's not thread-safe to do those operations, but that's not to say that you can't write to independent parts of the GU_Detail from multiple threads once you've created them. See also: http://www.sidefx.com/docs/hdk13.0/_h_d_k__g_a__using.html#HDK_GA_Using_Parallel

 

1. Yes, that's you how should use UT_Lock to serialize access

 

2. GU_DetailHandle's type of locking is for cache bookkeeping and is actually more of a reference counting system for GU_Detail. If there are no references to the GU_Detail (managed by GU_DetailHandle's, which are what all SOP_Node's use), then Houdini can free it from the geometry cache.

 

3. GU_Detail::merge() already has parts of the process multithreaded. I think you should think about the specifics of your use case rather than just a Duplicate SOP. Merging attributes is relatively expensive because it has to do it without a lot of knowledge. If you can create your geometry in a light weight representation for your problem, then it would be a lot faster if you first add all the attributes/points/primitives using default values and then write to the different attribute pages from multiple threads.

[Stalkerx777]

Thanks Edward!. THREADED_METHOD and locking detail object before writing did the job and now my code 4x times faster. However i'd like to try implement it in different fashion. So for example if i need 10 copies of input geometry to be placed in and deformed in space, i can do:

1) Duplicate geo 10 times:

const GU_Detail *copy = inputGeo(0);
int n = 10;
while (n)
    gdp->merge(*copy);
    n--;

2) Now, when i have 10 copies, i can use UTparallelFor and write to attib pages, however, my algorithm relies on index of each copy. I cant figure out how can i differ each copy in GA_PageIterator loop?

 

Thanks!

Edited November 11, 2014 by Stalkerx777

[edward]

To tell the difference you would need to know the number of points (for example) in the copy and then in each task that operates on a particular copy, you figure out where copy you're working on and subtract appropriately. They problem with doing after the merge like that though is that you can now potentially have two different copies sharing the same page of points, which you cannot (in general) safely write to from multiple threads as the same time. I forget but I think there might be options into the merge() which tell it to merge the copies without putting them in the same page though.