All, Evgueni's patch is a step in the right direction. Considering pthread_mutex_init as a conventional example, monitor shouldn't be locked at _init function. Test errors on Linux can just tell us that there are more places that rely on the incorrect contract of the function.
-- Alexei On 11/11/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:
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 >
-- Thank you, Alexei
