Synchronization underneath using pthread_mutex_lock/cond_wait

[Ro]

Hi,

I have been looking at the dvmLockObject() in dalvik/vm/Sync.c. In
there, Android uses the HW instruction ATOMIC_CMP_SWP. Using this
instruction, there is a spinlock implemented.
I was wondering why you did not use pthread_mutex_lock and cond_wait
instead, underneath Synchronization.
Instead of all the thin lock & fat lock concepts, would a pthread lock
per object have worked instead ?
Is the spinlock a performance advantage or is there some other
reason ?

Thanks,
Rohit

[fadden]

On Nov 3, 8:07 pm, Ro <rohitgirm...@gmail.com> wrote:
> Is the spinlock a performance advantage or is there some other
> reason ?

It's not really a spin lock. A spin lock tries to do the same thing
over and over until it succeeds. The thin-lock code wants to work
without interruption, so it's using an atomic compare-and-swap
operation. If the "old" value isn't what the code expects, it means
some other thread has come through and modified the state, so the code
needs to start over. If, when starting over, it discovers that the
lock has "fattened", it uses a different call path.

Thin locking has performance benefits over "fat" locking, since it can
be implemented as an inline atomic operation rather than a call to the
pthread library (which will, at a minimum, perform the same atomic
operation).

[Ro]

Hi,

Thank you for the info.
I have one more question regarding pthread mutex in android. I want to
use recursive pthread mutex lock. When I checked the file pthread.h
in /usr/include/pthread.h, I found there is an enum defined with
PTHREAD_MUTEX_RECURSIVE_NP in it.
So I used the below line for mutex initialization.
pthread_mutex_init(&clazz->replaylock,PTHREAD_MUTEX_RECURSIVE_NP);
However, when I compile and start the emulator, it dumps stack and
debug info. It does not start. When I check the dump I found that it
errors out at the line for mutex initialization.
Is there any other way to do this ? Or are recursive pthread mutex not
defined in android ?
Please let me know if you need additional info to understand my issue.

Thanks,
Rohit

[David Turner]

pthread_mutex_init's second argument must be a pthread_mutexattr_t pointer, not a PTHREAD_MUTEX_XXXX constant. Hence the crash

Don't assume that everything under /usr/include/pthread.h is going to be implemented by Android. Have a look at bionic/libc/include/pthread.h in your Android source tree instead.

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

[David Turner]

On Thu, Nov 4, 2010 at 4:07 AM, Ro <rohitg...@gmail.com> wrote:

Hi,

I have been looking at the dvmLockObject() in dalvik/vm/Sync.c. In
there, Android uses the HW instruction ATOMIC_CMP_SWP. Using this
instruction, there is a spinlock implemented.
I was wondering why you did not use pthread_mutex_lock and cond_wait
instead, underneath Synchronization.
Instead of all the thin lock & fat lock concepts, would a pthread lock
per object have worked instead ?

It may work, but on some platforms, a pthread_mutex_t is a really large object and each lock operations is very costly (e.g. with GLibc, I think it's a minimum of 16 bytes, and each lock must, in addition to the lock itself, add the mutex to a global list just in case the thread is later cancelled through pthread_cancel()).

On Android, mutexes are 4 bytes, lock operations are quite fast, though a bit slower than performing the atomic swap directly, and we don't support pthread_cancel(), but Dalvik aims to be portable, so using a pthread_mutex_t *per* object would be totally overkill.

 

Is the spinlock a performance advantage or is there some other
reason ?

Thanks,
Rohit