; Problem Set 12 

; NOTE: This problem is NOT like the one I was trying to invent on the fly in
; class!  It is a completely different problem that still involves exceptions!

; Today in class we saw that the actual JVM specification for MONITOREXIT
; included some behavior that M5 doesn't model: MONITOREXIT can throw
; exceptions.

; Below I show a new M5-style specification of MONITOREXIT -- a specification
; more accurate for the JVM -- and ask you to change the semantics of our old
; MONITOREXIT to be this new semantics.  You might want to actually carry out
; your redefinition in ACL2 (or ACL2s).  To redefine a function in ACL2 (or
; ACL2s), first execute the command (REDEF).  Thereafter, you will be able to
; redefine any user-defined function.  You may assume that the built-in class
; table includes an entry for a class named "Exception".

; New specification for MONITOREXIT (modeled more closely on the JVM):

; (MONITOREXIT)

; Stack: ..., objectref  =>  ...

; Description:  objectref must be a reference to an object in the heap.  The
; current thread should be the owner of the monitor associated with the
; instance referenced by objectref and the counter indicating the number of
; times it has entered this monitor should be non-zero.  The thread decrements
; the counter and, if the value is then zero, releases the monitor.

; Exceptions:  If the object is not a reference or if it is a reference
; but the current thread does not own the monitor or the counter is zero,
; MONITOREXIT throws an "Exception".

; Problem: Change the semantics of our MONITOREXIT to implement this more
; accurate specification.  All that is required is for you to exhibit
; the new definition of execute-MONITOREXIT and any functions
; you redefine or introduce.