harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salikh Zakirov <Salikh.Zaki...@Intel.com>
Subject Re: [drlvm][threading] questions about 3288, new patch 0002*
Date Fri, 16 Mar 2007 16:42:06 GMT
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.


-- 
Salikh Zakirov


Mime
View raw message