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

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

> 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

View raw message