Re: [xmlvm-users] XMLVM changes to synchronization

[Arno P. <ar...@pu...>]

thanks for the patch, Paul. Can you please upload it to the review 
system? I promise a swift turnaround reviewing it. I would like to make 
some general comments without having looked at your patch. In your mail 
you refer to jvm:monitorenter. We want to deprecate the JVM instructions 
and move to the DEX instructions. But as far as I know, the DEX 
synchronization instructions are pretty much identical.

I also wanted to say something about the associations. Panayotis has 
reported that they don't work in the simulator but do work on the actual 
device. Apparently you've implemented your own solution as a 
consequence. I would strongly advise against this. For one, it only 
matters if it works correctly on the device. I've heard many times that 
you cannot get around testing on the real device because of many subtle 
differences between the simulator and the device. So, we should optimize 
for the device; not the simulator. If the simulator version leaks 
memory, so be it. I'm sure Apple will fix that in the next version of 
the SDK.

More importantly, I favor using the tools given to us by the SDK. Apple 
undoubtedly put a lot of effort on implementing these associations 
efficiently and rather than inventing our our mechanism, we should use 
theirs. So, to be honest, I am reluctant to commit your patch in its 
current form.

Arno


On 7/17/10 12:36 AM, Paul Poley wrote:
> This is a pretty critical change, so please bare with me on the length
> of this e-mail.
> I have attached some source code that may be the best explanation. (See
> TestSync.java specifically)
>
> The major points are:
>
>    1. Changing XMLVM's synchronization
>    2. Implementing wait(), wait(long), notify(), notifyAll()
>    3. Considering alternatives to associative references to store member
>       variables in java_lang_Object
>
>
> In order to implement wait() and wait(long) in Objective-C, I must first
> take more control of synchronization.
> This is because these 2 methods release the Object's monitor for another
> thread while waiting.
>
> So while @synchronized has been the perfect solution for
> "jvm:monitorenter" and "jvm:monitorexit" before this point, it is not
> longer sufficient because it is scope based.
> I.e. I need to be able to release the Object's monitor for another
> thread when calling wait() or wait(long) and then retain the monitor
> again when the wait is over.
>
> My solution is to use NSLock, while accounting for exceptions and
> recursive locks.
> Java style, the following requires conversion:
>
> *    synchronized (this) {*
> *        // Do something*
> *    }*
>
> It would be converted to:
>
> *    acquireLockRecursive();*
> *
> *
> *    try {*
> *        // Do something*
> *    } finally {*
> *        releaseLockRecursive();*
> *    }*
>
> First every Object needs:
>
> *    private NSLock myLock; // the lock which to use for the Object in
> place of synchronizing on "this"*
> *    private int recursiveLocks = 0; // the number of recursive locks.
> If only synchronized once, this is 1*
> *    private Thread owningThread; // the thread that owns the Object's
> monitor or null for none*
>
> More in depth is:
>
> *    private void acquireLockRecursive() {*
> *        boolean acquireLock = false;*
> *        synchronized (this) {*
> *            acquireLock = Thread.currentThread() != owningThread;*
> *        }*
> *
> *
> *        if (acquireLock) {*
> *            myLock.lock();*
> *            synchronized (this) {*
> *                owningThread = Thread.currentThread();*
> *            }*
> *        }*
> *        recursiveLocks++;*
> *    }*
> *
> *
> *    private void releaseLockRecursive() {*
> *        recursiveLocks--;*
> *
> *
> *        if (recursiveLocks == 0) {*
> *            synchronized (this) {*
> *                owningThread = null;*
> *            }*
> *            myLock.unlock();*
> *        }*
> *    }*
>
> Unfortunately, associative references do not work in the simulator, so I
> do not believe this to be a viable option for member variables at this
> point.
> I don't think it would be prudent to stop allowing XMLVM to operate in
> the simulator entirely.
> Hopefully we can come up with a universal solution (maybe changing
> java_lang_Object to inherit from NSObject instead of be one, but that
> causes other issues).
>
>
> I have attached the source code prototypes.  For the current
> conversation, see TestSync.java.  In a later conversation, we can
> discuss TestObject2.java.
> I made a crude Java implementation of NSLock & NSConditionLock.  They
> work for this scenario, but are not intended for general use.
> Also, note that they are backed by wait(), wait(long) & notifyAll(),
> which is somewhat ironic since that's what we're trying to implement.
>
>
>
> Once all this is done, I can move on to wait() and wait(long) where they
> can unlock() and lock() around the waiting period.
> Please give me any input, positive or negative!  If you disagree with
> anything or everything, I would be interested in hearing those thoughts
> as well.
>
> Thanks,
> Paul Poley
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users