On renderscripts and thread-safety

Question

I have always assumed that renderscripts are threadsafe with forEach across an allocation. To aid in my debugging, can someone confirm this?

(I'm seeing a static array value check succeed, but using rsDebug shows that the check should have failed.

static uint32_t state[16];
static void f(); // modifies state.

/* snip... */

void
root(const uint32_t *in, uint32_t *out)
{
  /* snip... */

  f(); 

  if(state[0] == 0)
  {
      rsDebug("state[0]", state[0]);
      *out = 1;
  }
}

I see printed state[0] with a nonzero value!)

score 0 · Accepted Answer · answered Sep 03 '13 at 06:05

0

Each cell is expected to execute independently of the other cells. If you are writing to other cells of your input (or output) Allocation, you can certainly trigger undefined behavior. This is no different than any other multithreaded computation model, however. Can you show your kernel code exactly and describe how you are calling it?

answered Sep 03 '13 at 06:05

Stephen Hines

2,612
1
13
12

My code should be acting entirely pointwise. The entire script is too long, but I'll summarize it above. This gets called with a forEach_root call from Java. (I know there was some mention about scripts not being called synchronously, but does that apply to static fns?) – zeta Sep 03 '13 at 22:38
1

You are indeed relying on undefined behavior here. If your function f() modifies state, you can't have independent threads of root() expect to see (or not see) those changes. Think of it like this: the RS driver could run all of the threads for root() sequentially or simultaneously. If your algorithm/kernel behaves differently based on that, you need to do something different. – Stephen Hines Sep 04 '13 at 02:36
OK. I think by extension you are saying that Renderscript does not guarantee that `state` will not be modified by other threads, and therefore the kernel as I have described it above is not threadsafe. Have I understood correctly? – zeta Sep 04 '13 at 06:03
Correct. RS does not make multiple copies of state to keep constant throughout the execution of every other thread. You need to be aware of data races that you might be causing (much like how this same problem comes up under any multithreaded environment). – Stephen Hines Sep 04 '13 at 09:16

On renderscripts and thread-safety

1 Answers1