How to correctly use a fixed size thread pool?

I am quite new to using concurrency in Java, so please forgive if this is a trivial question.

I would like to make use of something like pool=Executors.newFixedThreadPool(n) to automatically use a fixed number of threads to process pieces of work. I understand that I can asynchronously run some Runnable by one of the threads in the threadpool using pool.execute(someRunnable).
My problem is this: I have some fixed amount of N datastructures myDS (which are not reentrant or sharable) that get initialized at program start and which are needed by the runnables to do the work. So, what I really would like to do is that I not only reuse N threads but also N of these datastructures to do the work.

So, lets say I want to have 10 threads, then I would want to create 10 myDS objects once and for all. Each time some work comes in, I want that work to get processed by the next free thread, using the next free datastructure. What I was wondering is if there is something in the library that lets me do the resusing of threads AND datastructures as simply as just reusing a pool of threads. Ideally, each thread would get associated with one datastructure somehow.

Currently I use an approach where I create 10 Runnable worker objects, each with its own copy of myDS. Those worker objects get stored in an ArrayBlockingQueue of size 10. Each time some work comes in, I get the next Runner from the queue, pass it the piece of work and submit it to the thread pool.
The tricky part is how to get the worker object back into the Queue: currently I essentially do queue.put(this) at the very end of each Runnable's run method but I am not sure if that is safe or how to do it safely.

What are the standard patterns and library classes to use for solving this problem correctly?

I have tried to solve problems a bit like this using what I call a "token" or a work order request. Basically I invent some structure to use as the work flow state tracking, as something makes its way into a thread pool of workers. The motivation being that everything specific to the state of doing something lives within this "request" object, which is used by a thread pool worker to do its thing and when completed, the worker updates a status or flag on it.

This facilitates synchronous blocking on the parent invoking thread, your code can ue the wait() and notify() thread API to block, where the worker thread invokes notify() when its finished.

For example, I define an interface,

Code:

---

public interface Token {
 
  void process();
 
  /**
  * 
  * @return true when the threaded workers have finished doing their thing.
  */
  boolean isComplete();

  /**
  * implementation blocks until it is complete
  */ 
  void waitForComplete() throws InterruptedException;
}

---

and then i implement this in my specific (myDs class) and stuff the work the thread is supposed to do into process() method. where my threaadpool in this case knows to look for and work with a Vector<Token> as its input queue.