Re[2]: slowLockMutex / putHeavyLock

[Patrick Tullmann]

Maxim Kizub wrote:
> GB> Which COMPARE_AND_EXCHANGE macro does it use?

This is still an important question.  There is a completely bogus
definition of COMPARE_AND_EXCHANGE() for architectures on which we do
not have an atomic compare and swap operation.

In locks.c, change the second definition of COMPARE_AND_SWAP() to a
#error directive and recompile.  (We should probably do this, or
perhaps protect it with jmutexes?)


> Let me try. But note - sometimes I had asserts
> related to synchronization, and they were "false".
> I mean, I have a dual processor machine, and,
> for example, and asseret
> assert(xxx==0 && yyy==0)
> was caught, but debugger shows, that both
> xxx and yyy are nulls. Probably, that's
> because of my dual-processor computer...

That seems pretty unlikely to me...


[... backtraces ...]

> Ok, I hope this will help.  BTW, I see now that this is a secondary
> error, because one of threads tryes to throw an error
> "IllegalMonitorState", but anyway -
> 1. why program has caused it?

I belive the synchronization primitives are fubar on your system.  It
could be the jmutex implementation, or (my guess) the
COMPARE_AND_EXCHANGE macro.

> 3. Take, for example, this code:
>
> [ _lockMutex() ]
>
> 
> as you see - lkp is not protected at all.

The COMPARE_AND_EXCHANGE is supposed to provide all the protection.

Have you looked at FAQ/FAQ.locks?  It tries to describe the locking
algorithm (thought I think its wrong wrt to the exact relationship
between threads and ksems.)

> If val != 0, this doesn't mean that in next statement it's != 0,
> i.e. in this time another thread may execute some code to change
> lkp.

I'm not sure about this... Mostly because the scenario you describe
could happen on a uniprocessor (by switching threads right after the
val == 0 check)...  

Still, I can't convince myself that you're wrong by looking at the
code.  However, instead of using spinon/spinoff, I think the (val ==
0) check could just be replaced with an immediate call to
COMPARE_AND_EXCHANGE (which should be atomic wrt the
COMPARE_AND_EXCHANGE in _unlockMutex() that sets *lkp to NULL).

Anyone else want to chime in with a clue on this stuff?

-Pat

----- ----- ---- ---  ---  --   -    -      -         -               -
Pat Tullmann                                       tullmann@cs.utah.edu
 Thisemailhasbeenbroughttoyoubycocacolafavoredbyprogrammerseverywhere