Question regarding the configure function in mutex.c

[afwang]

I've been reviewing some of the code here since it'll be used in the Ogame app. Within mutex.c, in the eu_codlab_sharedmutex_Mutex_configure function, why is there no call made to pthread_mutex_init to initialize the memory region pointed to by the semaphor variable? The Ogame app code will call lock() on semaphor before the memory region ever gets initialized.

Also, what is the purpose of creating a pointer to a C string representation of a Java String object in the configure function? A reference is created and released, but the data is never used anywhere within the function.

[codlab]

The mutex initialization is supposedly made once in the ApplicationController instance. Each instance of the same process share the same mutex instance (the main difference between thread versus process shared memory)

For now, the initialization string is not used internally, I still did not finished to set this as the equivalent of the path/key string used in posix mutexes

Le lun. 27 juil. 2015 01:39, afwang notifications@github.com a écrit :

I've been reviewing some of the code here since it'll be used in the Ogame app. Within mutex.c, in the eu_codlab_sharedmutex_Mutex_configure function, why is there no call made to pthread_mutex_init to initialize the memory region pointed to by the semaphor variable? The Ogame app code will call lock() on semaphor before the memory region ever gets initialized.

Also, what is the purpose of creating a pointer to a C string representation of a Java String object in the configure function? A reference is created and released, but the data is never used anywhere within the function.

— Reply to this email directly or view it on GitHub https://github.com/codlab/android_process_mutex/issues/1.

[afwang]

I still don't quite understand because I am still not quite sure where the mutex's memory area is initialized. Please help me see if there is something wrong with my understanding:

I will try explaining my thoughts completely with the list of steps the application follows when the application is started from a cold start:

1. When the app starts from a cold start, the program flow first goes through ApplicationController's onCreate.
2. The flow eventually enters the AccountsManager.getInstance method.
3. Since the application is started from a cold start, this method calls createNewInstance, which calls the constructor for AccountsManager.
4. The AccountsManager constructor calls the superclass AbstractController's constructor.
5. AbstractController's constructor then calls Mutex's constructor.
6. Before the Mutex constructor is called, the class gets loaded, its static initializer loads the library, and the native JNI_OnLoad function. The OnLoad function does not handle anything involving shared memory for the mutex.
7. Returning to the Mutex constructor, this constructor then calls the native method configure.
8. The configure function allocates some shared memory using shmget, and then it obtains a pointer to this shared memory area using shmat.
9. Ignoring the JNI string methods being called, configure returns, and the program control returns back to the ApplicationController onCreate method.
10. Steps 2 through 9 are repeated for the CookiesManager instance.

Please note that during all these steps, the shared memory area for the mutex has just been allocated, but it has not been initialized (no call to pthread_mutex_init has been made).

After application setup, the NoAccountActivity is loaded. The mutex lock does not get touched until the user tries logging in for the first time. In this case, the onLoginClicked() method will be called:

1. NoAccountActivity.onLoginClicked called.
2. onLoginClicked calls the addAccount method.
3. addAccount tries to add the account to the database using AccountsManager's addAccount method.
4. AccountsManager's addAccount method calls its overloaded partner method (the other addAccount).
5. The overloaded addAccount method calls lock(), which is just a wrapper around calling the Mutex class's lock() method.
6. Since the Mutex class's lock method is a native method, we defer to the library method.
7. The implementation for lock() is just a call to pthread_mutex_lock(semaphor).

At this point, a call has been made to pthread_mutex_lock before pthread_mutex_init has been called on the memory area. Is this an error?

I believe there are some possibilities, that I knew where at least one was true, would help my understanding:

1. pthread_mutex_init does nothing more than fill the entire shared memory region with 0's on all relevant architectures. In this case, since the memory area is already filled with 0's by shmget, a pthread_mutex_init call is not necessary.
2. There was a method call somewhere during the application or activity set-up that eventually made a call to pthread_mutex_init, and I did not see this chain of calls.

Sorry about being so persistent about this, but it's something that I need to understand so I can know what's going on with the code.

I will try adding some print statements or using a debugger to take a look at the lock() method. Would you mind if I submitted a pull request if I find something?

[codlab]

In the ApplicationController instance, a mutex initialisation is done via the overloaded constructor

Le lun. 27 juil. 2015 06:23, afwang notifications@github.com a écrit :

I still don't quite understand because I am still not quite sure where the mutex's memory area is initialized. Please help me see if there is something wrong with my understanding:

I will try explaining my thoughts completely with the list of steps the application follows when the application is started from a cold start:

1. When the app starts from a cold start, the program flow first goes through ApplicationController's onCreate.
2. The flow eventually enters the AccountsManager.getInstance method.
3. Since the application is started from a cold start, this method calls createNewInstance, which calls the constructor for AccountsManager.
4. The AccountsManager constructor calls the superclass AbstractController's constructor.
5. AbstractController's constructor then calls Mutex's constructor.
6. Before the Mutex constructor is called, the class gets loaded, its static initializer loads the library, and the native JNI_OnLoad function. The OnLoad function does not handle anything involving shared memory for the mutex.
7. Returning to the Mutex constructor, this constructor then calls the native method configure.
8. The configure function allocates some shared memory using shmget, and then it obtains a pointer to this shared memory area using shmat.
9. Ignoring the JNI string methods being called, configure returns, and the program control returns back to the ApplicationController onCreate method.
10. Steps 2 through 9 are repeated for the CookiesManager instance.

Please note that during all these steps, the shared memory area for the mutex has just been allocated, but it has not been initialized (no call to pthread_mutex_init has been made).

After application setup, the NoAccountActivity is loaded. The mutex lock does not get touched until the user tries logging in for the first time. In this case, the onLoginClicked() method will be called:

1. NoAccountActivity.onLoginClicked called.
2. onLoginClicked calls the addAccount method.
3. addAccount tries to add the account to the database using AccountsManager's addAccount method.
4. AccountsManager's addAccount method calls its overloaded partner method (the other addAccount).
5. The overloaded addAccount method calls lock(), which is just a wrapper around calling the Mutex class's lock() method.
6. Since the Mutex class's lock method is a native method, we defer to the library method.
7. The implementation for lock() is just a call to pthread_mutex_lock(semaphor).

At this point, a call has been made to pthread_mutex_lock before pthread_mutex_init has been called on the memory area. Is this an error?

I believe there are some possibilities, that I knew where at least one was true, would help my understanding:

1. pthread_mutex_init does nothing more than fill the entire shared memory region with 0's on all relevant architectures. In this case, since the memory area is already filled with 0's by shmget, a pthread_mutex_init call is not necessary.
2. There was a method call somewhere during the application or activity set-up that eventually made a call to pthread_mutex_init, and I did not see this chain of calls.

Sorry about being so persistent about this, but it's something that I need to understand so I can know what's going on with the code.

I will try adding some print statements or using a debugger to take a look at the lock() method. Would you mind if I submitted a pull request if I find something?

— Reply to this email directly or view it on GitHub https://github.com/codlab/android_process_mutex/issues/1#issuecomment-125082411 .