[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "Another thread runs exclusively already." exception

Thanks for the response Falko.

We are seeing this on both MP and UP machines. It (seems to) happens not when more
than one thread is started, but when it is done very rapidly.  So the tester has a
command line argument as to how many query threads to start and run.  IF this
number is, say, 10, no problem.  If it is 100 problem  Actually with 100 not only
does this happen but an 'out of memory' exceptions is thrown as well, and this is
problematic.  I'll look into that later.

Now, when 10 threads are started and finished, if I hit the up arrow key and hit
enter to re-execute, again no problem.  If I do it a third time, problem.  So it
doesn't seem to always happen repeatedly.  One thing that will ALWAYS cause it is
to start more than one thread that is in a loop that queries the users defined in
the database.  So the first tread starts and - until the tester is stopped -
continually queries for defined users.  If a second thread is started that does
the same thing, the exception is thrown.  This really shouldn't happen.

The version I am using is 0.5-dev2.  The line of code you reference is there,
after the check is made.  Shouldn't that be the first line of code executed inside
the method?  That way the first thread there is given the higher priority thus
preventing another thread from possibly executing the check code before the first
thread get the higher priority?

I see the code commented out dealing with stopping the other thread.  What was
wrong there?

Again, thanks.

Falko Braeutigam wrote:

> --snip--

> A better implementation would actually suspend all other threads. But this is
> not as simple as it sounds.
> Also, your log shows that exactly after calling beginExclusion() another thread
> is executed, which is strange even on a multi processor. Which ozone version do
> you run. Check the code of beginExclusion. Is there a line like:
>        Thread.currentThread().setPriority (Env.TRANSACTION_MUTEX_PRIORITY);