harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject [drlvm][threading] questions about 3288, new patch 0002*
Date Fri, 16 Mar 2007 00:35:12 GMT
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.  Some

Why not call this API "os_thread_force_memory_barrier_other"?

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.

Other than that, I am actually very happy with 0002* since it basically
reimplements a cleaned up version of what was in ORP a long time ago.  This
code is much more readable.

Weldon Washburn
Intel Enterprise Solutions Software Division

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