Marc,
I've rewritten EntityInstanceInterceptor a little(see my race condition fix
email please) and put it some code so that LOCKING-WAITING isn't printed a
zillion times. I also added a Thread.yield() before continue; in the
lock-do-while-loop.
I've also started looking into ditching the do..while loop in favor of
wait/notify. It's much more complicated than I originally anticipated, but
I'm making progress. IMHO, the whole locking business should be ditched
when you have commit-option-C. Let the database to the synching for you
with the select-for-update feature(CMP) or make the BMP developers handle
the locking.
Bill
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of marc
> fleury
> Sent: Sunday, June 10, 2001 10:05 PM
> To: Jboss-Development@Lists. Sourceforge. Net
> Subject: [JBoss-dev] FW: Busy wait on one thread
>
>
> busy wait problem, see original message below
>
> we are on top of it, as of may 10...
>
> again vinay, please pay my (due) respects to matt, do say that it is NOT a
> full busy wait (I.e. n-1 threads go to sleep) but one thread ALWAYS goes
> through and therefore under high load it can become a problem...
>
> I will try to fix this this week as simone is visiting napa valley and 17
> miles drives (btw he is a VERY nice guy)...
>
> marcf
>
> |-----Original Message-----
> |From: Bordet, Simone [mailto:[EMAIL PROTECTED]]
> |Sent: Thursday, May 10, 2001 5:59 PM
> |To: 'marc fleury'
> |Subject: R: Busy wait on one thread
> |
> |
> |Hi Marc,
> |
> |> Simone,
> |>
> |> ok the semaphore stuff lets' one go through but you release
> |> the semaphore
> |> before you do the execution of the code. Therefore we lock
> |> the instance and
> |> then release the semaphore mutex and the next thread comes in.
> |>
> |> If you have 2 threads, one comes in passes the mutex,
> |> acquires the ctx lock
> |> and releases the mutex. It then goes on to execute an update
> |> that takes,
> |> for example, one minute.
> |>
> |> The second thread comes in, passes the mutex (no one is
> |> there), try to get
> |> the ctx lock but sees it is locked and just goes on logging
> |> "LOCKING-WAITING" and TRIES AGAIN.
> |>
> |> This gives rise to tons of LW messages with 2 threads
> |>
> |> This is a busy wait for one thread, you do not sync on the
> |> state of the
> |> target context since your release is just on the mutex.
> |>
> |> Unless I am missing something, we need to rethink this a bit.
> |> I will make
> |> the time to fix it
> |
> |Correct.
> |I already had heavy sessions on it say one month ago, but did
> not finished,
> |and then got damn busy at work.
> |FYI, I changed the busy wait to a wait-notify (I already commited the
> |utility class WaitSemaphore under jboss/util for that, but not the
> |interceptor), then run into troubles with the instance pool and the
> |transactions (commit C), finally I thought "I should debug one thing at a
> |time", and eventually run out of time. I'm a bit upset for this,
> I'd really
> |like to spend much more time on JBoss...
> |After June I should have more time, at work the pressure should lighten.
> |Anyway I'm open to help anyone wants to take a cranck on that
> code, or fix
> |it myself when I'll have more time, just let me know.
> |Oh, I will spend 3 weeks (summer holidays) in US after JavaOne,
> |maybe we can
> |keep in touch and have a beer together, why not ?
> |
> |Regards,
> |
> |Simon
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
