What you have posted so far isn't enough to advice for a workaround.
Not very experienced in threads myself either.

What I know is that when a resource is accessed in 1 thread, even a mere variable,
any other threads have to wait for their own turn!

A line like this one below:
while ( !imgs.isEmpty() );

is enough to halt an entire program. B/c in that loop, that resource is accessed so fast and doesn't give any room for the thread responsible to empty that Queue do its job.

To fix that, I had to insert a delay() on it, so the other thread could have more chances to access it too:
while ( !imgs.isEmpty() )    delay(100);

The source post of that program is:
http://forum.processing.org/topic/save-frames-per-second

Threads and concurrency is slippery topic. And it probably takes couple of years to become really good with threads. So don't be discouraged, threads are keeping many programmers sleepless for weeks :)

How big (resQ) are the arrays?

You might try the arrayCopy method as this will be quicker than a user defined for-loop.

Personally I would have the each array shared between the event (has draw method) and user-created thread and use a boolean flag to control access to them. There are other ways of controlling access but they are more complicated. Oh and BTW as GoToLoop says put a small delay in the user-created thread to allow the event thread to draw.

First thanks to all the answers - I'll try Your proposal and give report.
Meanwhile, as some of You asked for more code:

first, the thread:
class ThreadSXL extends Thread
{
  int pauseTime;
  boolean run = true;
  boolean exe = false;
  boolean write = false;
  boolean pause = false;
  int c =0;
  int s, e;
  float[] disp;
  float[] wall;

  ThreadSXL(int theS, int theE)
  {
    pauseTime = 1;
    s =theS;
    e = theE;
    disp = new float[resQ];
    wall = new float[resQ];
  }


  public void run()
  {
    while (run)
    {
      if (exe && !pause)
      {
        diffuseCC();
      }
      if (write)
      {
        write();
      }
    }
  }

  void diffuseCC()
  {
    float dAll, wAll;

    for (int i=s; i<e; i++)
    {
      if (i==0) c++;
      dAll =0;
      wAll =0;
      for (int j=0; j<Spaxels[i].theNN.size(); j++) {  // theNN means: each "Spaxels" stores its neighbors
        Spaxel any = Spaxels[i].theNN.get(j);         // in an ArrayList, as the Spaxels at the edge of the field
        dAll += any.disp;                                       // have less neighbors, than those in the middle
        wAll += any.wall;
      }

      disp[i] = dAll/Spaxels[i].theNN.size();
      wall[i] = .99*wAll/Spaxels[i].theNN.size();
    }
  }

  void write() {
    for (int i=0; i<resQ; i++) {
      buffy.disp[i] = disp[i];
      buffy.wall[i] = wall[i];
    }
    write = false;
  }
}

ThreadSXL t1;//, t2, t3, t4, t5, t6;//, t7;

void initThreadSXL()
{
  t1 = new ThreadSXL(0, resQ);
  t1.start();
}

second the (probably needless) buffer-class
buffer buffy = new buffer();

class buffer
{
  float[] disp = new float[resQ];
  float[] wall = new float[resQ];

  buffer() {
    for (int i=0; i<resQ; i++) {
      disp[i]  = 0.5;
      wall[i]  = 0.5;
    }
  }
}

third, a class-intern method of the field-objects, where they get the values:

  void getField()
  {
    if (!acOwned && !ccOwned && !border) {
      t1.exe = false;
      disp = buffy.disp[myI];
      wall = buffy.wall[myI];
      t1.exe = true;
      t1.write = true;
    }
  }

"(!acOwned && !ccOwned && !border)" means, that they only recieve their values from their neighbours, if no node-Object is on them. If so, they recieve their values from the node-object. As you can see from the attached picture: I am trying to derive a spacing-system from the interactions of agents - so that's why all the different classes an objects.  

My best guess would be that there's something with getField() or the way it's used. How are you calling getField()? I guess you call it from main thread from draw()   [or methods used in draw]? 

Sometimes it helps to think of threads as of "humans doing actions" (why not? if Einstein when thinking about particles was imagining that he was "sitting on top of electron", then everything is allowed).

I totally agree with

So the boundaries are less the limits of computation but the limits of the programmers comprehension

A performance re-writing attempt for diffuseCC() method:

import java.util.List;

void diffuseCC() {
  final ???[] spax = Spaxels; // dunno data-type of it!

  if (s == 0)  ++c;

  for (int i = s; i != e; ++i) {
    final List<Spaxel> nn = spax[i].theNN;
    final int nnSize = nn.size();
    float dAll = 0, wAll = 0;

    for (int j = 0; j != nnSize;) {
      final Spaxel any = nn.get(j++);
      dAll += any.disp;
      wAll += any.wall;
    }

    disp[i] = dAll / nnSize;
    wall[i] = wAll*.99 / nnSize;
  }
}

Dear all,

I am back from 20-22 fps (well I added some more behaviour algorithms meanwhile) to something between 37 to 41 fps (depends on how many walls the systems has got to draw). I am already using a GL-Unit and only draw the surfaces, that can be seen, and still - graphics eats up more performance then anything else. But this I knew before and this wasn't the question. Anyway your proposals gave me the ideas I needed to restructure my methods. Now I've got some more air to improve and refine the system.
Thank you all for racking your brains, I appreciate it.

I do not yet understand, what "final" does except making a variable static,...

Actually in Java, keyword final has nothing to do w/ keyword static.
For local variables, final only asserts the programmer's compromise of not changing that variable's value once set, until the end of its scope. Otherwise, program refuses to compile! It's more like a reminder.
Although for field primitive variables plus String, final can grant some slightly performance boost! 

... it gives me a performance-increase within the thread of about 15%, which is a good thing...

Well, at least I know that it's made some effect! 
What I did was caching as many field variables as local variables.
Until the latest objective -> reach float variables disp & wall. 
That was a long road though. So many structures to get there!