hmmm.... strange. The patch was tested on multi-processor system running SUSE9. I will check if the patch misses something. Anyway, we need to wait with the patch submission until we 100% sure how hythread_monitor_init should behave.
Thanks Evgueni On 11/11/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
On Friday 10 November 2006 17:45 Evgueni Brevnov wrote: > Hi, > > While investigating deadlock scenario which is described in > HARMONY-2006 I found out one interesting thing. It turned out that DRL > implementation of hythread_monitor_init / > hythread_monitor_init_with_name initializes and acquires a monitor. > Original spec reads: "Acquire and initialize a new monitor from the > threading library...." AFAIU that doesn't mean to lock the monitor but > get it from the threading library. So the hythread_monitor_init should > not lock the monitor. > > Could somebody comment on that? It might be that semantic is different on different platforms which is probably even worse. Your patch in HARMONY-2149 breaks nearly all of acceptance tests on Linux while everything on Windows works (ok I tested on laptop with 1 processor while Linux was a HT server, sometimes it is important for threading). I think we need more investigation on whether or not the monitor has to be locked in init. -- Gregory Shimansky, Intel Middleware Products Division
