http://sablevm.org/bugs/show_bug.cgi?id=92
[email protected] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
------- Additional Comments From [email protected] 2005-01-28 21:42 -------
I just got my high-speed connection back, so time to put some comments.
As I said twice in our IRC conversation, it's not a fix, but a workaround.
Basically, we're waiting until the cached variable is coherent with the main
emory, which (due to C&S) will happen after single C&S on that variable, so
I don't think we really have a spinlock here. Please also note that it was
a late-night solution. I am sure if anyone is interested - it shows the
right direction to the real solution.
What I suspect is the problems here, is that when we read instance->lockword
we read it from cache, not from the main memory, thus we might end up
adding ourselves to waiting list of thread that does not own this lock
anymore (this is what the assertion failure shows us).
I imagine the real solution to that would be:
Jan 28 00:50:17 <gadek_> cjfp: you probably should have a "read with
lock" or something to read the lockword w/o caches.
Another problem with original code, even on UP is that we read
instance->lockword *twice* in the conditional. What if at the first
read the lockword was thin, but then when we read it again to get thread
ID, it got changed meanwhile???
I suspect there's more little implementation quirks like that.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are the QA contact for the bug, or are watching the QA contact.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.