harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][threading] questions about 3288, new patch 0002*
Date Sat, 17 Mar 2007 15:07:22 GMT
On 3/16/07, Salikh Zakirov <Salikh.Zakirov@intel.com> wrote:
>
> Weldon Washburn wrote:
> > Salikh,
> > I am looking at both Linux and Windows versions of
> os_thread_yield_other().
> > Both have the comment, "causes the other thread to have a memory barrier
> by
> > suspending and resuming it."  AFAICT the code you wrote probably does
> this
> > as a side effect of suspending and resuming the target thread.
>
> This is not the code I have written. I took it from
> vm/port/src/thread/*/apr_thread_ext.c.
>
> I chose not to change the naming conventions, and leave that to a later
> cleanups and improvements.
>
> Frankly speaking, I am not exactly sure why this API is needed at all.
>
> > Some
> > observations:
> >
> > 1)
> > Why not call this API "os_thread_force_memory_barrier_other"?
>
> That's a good idea to rename it. I did not do it to keep the patch impact
> at
> lowest. Please feel free to go ahead and commit the rename. (after 3288 is
> committed).
>
> > 2)
> > Given that the calling thread does not actually know what the target
> thread
> > is executing, what is the value of forcing the target thread to execute
> a
> > memory barrier?  The only way I can think that the calling thread would
> be
> > absolutely certain about the target thread's IP is if the calling thread
> > waited for the target thread to block on something like a critical
> section.
> > If the target thread is blocked, the OS will flush out the write-back
> > buffers during context switch and speculative reads will be tossed.  In
> > other words, forcing a memory fence is redundant.
>
> I suspect that this function could have been introduced to optimize thread
> suspension time on a true multiprocessor, and it is a pity that authors of
> this
> code did not leave an explanation.
>
> Probably we can experiment with removing this call and see if performance
> degrades in any way.



If removing this call has any impact, I would expect performance to
improve.  As far as I can tell, os_thread_yield_other/apr_thread_yield_other
do not actually impact the correctness of the system.  However, they may be
masking race conditions that need fixing.  I will start another thread on
this topic.

--
> Salikh Zakirov
>
>


-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message