harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "史成荣" <icyr...@gmail.com>
Subject Re: [drlvm][jitrino]
Date Sat, 15 Dec 2007 12:46:10 GMT
2007/12/15, Gregory Shimansky <gshimansky@apache.org>:
>
> On 15 December 2007 史成荣 wrote:
> > I still have 2 questions.
> >
> > First, I know in the Thread Manager, it is the
> > hythread_thin_monitor_try_enter method to aquire the mutex lock
> > and implement the *memory barrier.* But* *I looked into the code of this
> > method, didn't find any memory barrier operations(including the
> > apr_memory_rw_barrier() call and  cmpxchg operation) when it is the fat
> > lock. when aquiring the fat lock, it calls the
> hythread_monitor_try_enter
> > method. In the hythread_monitor_try_enter method* there isn't *memory
> > barrier operations, but has a call of the *hymutex_trylock* method. Does
> > the hymutex_trylock method also has barrier effect built-in?
>
> Fat monitors use OS synchronization primitives. You can take a look in
> vm/thread/src/{win,linux}/os_mutex.c files to see the exact
> implementation.


I had taken a look into vm/thread/src/{win,linux}/os_mutex.c files, and
found pthread_mutex_trylock(linux) and TryEnterCriticalSection(win) methods.
Do you mean the two methods not only have mutex lock function, but also have
barrier effect?


> > Second, when exit the synchoronized area, it should release the mutex
> lock
> > and flush the local memory to the main memory. But the
> > hythread_thin_monitor_exit method only release the mutex lock and I
> don't
> > find any flushing operation in hythread_thin_monitor_exit method.
> >
> > I think there must be some mistakes of my idea, hoping for your advice.
>
> --
> Gregory
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message