[jira] Updated: (HARMONY-3900) [drlvm][thread] Race condition at thread_native_thin_monitor.c:(675,654)

["Ilya Leviev (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HARMONY-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilya Leviev updated HARMONY-3900:
---------------------------------

    Attachment: SourceViewScreenshot-1.jpg

Source View screenshot added 

> [drlvm][thread] Race condition at thread_native_thin_monitor.c:(675,654)
> ------------------------------------------------------------------------
>
>                 Key: HARMONY-3900
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3900
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>            Reporter: Ilya Leviev
>         Attachments: SourceViewScreenshot-1.jpg
>
>
> TC report on thread unsafe access that result in race condition that occur during concurrent execution of locktable_put_fat_monitor and locktable_get_fat_monitor functions.
> Write -> Read data-race	
> Memory read at "thread_native_thin_monitor.c":654 conflicts with a prior memory write at "thread_native_thin_monitor.c":675
> Stack Trace: 
> Context
> 	Function void DrlEMImpl::executeMethod(struct _jmethodID *,union jvalue *,union jvalue *) "drlemimpl.cpp":509
> 	Function void JIT_execute_method_default(void *,struct _jmethodID *,union jvalue *,union jvalue *) "ini_ia32.cpp":199
> 	Function vm_invoke_native_array_stub "ini_ia32.cpp":76
> 	Function class VM_thread * get_thread_ptr_stub(void) "thread_manager.cpp":138
> 	Function m2n_free_local_handles "m2n_ia32.cpp":268
> 	Function hythread_thin_monitor_try_enter "thread_native_thin_monitor.c":341
> 	Function class VM_thread * get_thread_ptr_stub(void) "thread_manager.cpp":138
> 	Function jthread_monitor_enter "thread_java_monitors.c":117
> 	Function hythread_thin_monitor_try_enter "thread_native_thin_monitor.c":309
> 	Function locktable_get_fat_monitor "thread_native_thin_monitor.c":649
> 1st Access (Write)
> 	Function m2n_free_local_handles "m2n_ia32.cpp":268
> 	Function hythread_self "hythread.h":465
> 	Function class VM_thread * get_thread_ptr_stub(void) "thread_manager.cpp":138
> 	Function m2n_free_local_handles "m2n_ia32.cpp":268
> 	Function class VM_thread * get_thread_ptr_stub(void) "thread_manager.cpp":138
> 	Function hythread_suspend_enable "hythread_ext.h":370
> 	Function Java_java_lang_VMThreadManager_wait "java_lang_vmthreadmanager.cpp":202
> 	Function jthread_monitor_timed_wait "thread_java_monitors.c":308
> 	Function inflate_lock "thread_native_thin_monitor.c":599
> 	Function locktable_put_fat_monitor "thread_native_thin_monitor.c":675
> "674"	""	" "
> "675"	"*"	"     lock_table[id] = fat_monitor;"
> "676"	""	"     //hythread_global_unlock();"
> 2nd Access (Read)
> 	Function void DrlEMImpl::executeMethod(struct _jmethodID *,union jvalue *,union jvalue *) "drlemimpl.cpp":509
> 	Function void JIT_execute_method_default(void *,struct _jmethodID *,union jvalue *,union jvalue *) "ini_ia32.cpp":199
> 	Function vm_invoke_native_array_stub "ini_ia32.cpp":76
> 	Function class VM_thread * get_thread_ptr_stub(void) "thread_manager.cpp":138
> 	Function m2n_free_local_handles "m2n_ia32.cpp":268
> 	Function hythread_thin_monitor_try_enter "thread_native_thin_monitor.c":341
> 	Function class VM_thread * get_thread_ptr_stub(void) "thread_manager.cpp":138
> 	Function jthread_monitor_enter "thread_java_monitors.c":117
> 	Function hythread_thin_monitor_try_enter "thread_native_thin_monitor.c":309
> 	Function locktable_get_fat_monitor "thread_native_thin_monitor.c":654
> "652"	""	"     assert(lock_id >=0 && lock_id < table_size);"
> "653"	""	"     //hythread_global_lock();"
> "654"	"*"	"     fat_monitor = lock_table[lock_id];"
> "655"	""	"     //hythread_global_unlock();"
> "656"	""	"     return fat_monitor;"
> See also Source View screenshot.
> Notes on Write->Read race conditions.
> ---------------------------------------------------
> Write->Read data races occur when one thread writes a shared memory location (address) while another thread concurrently reads the same memory location.  
> The shared memory location may be referred to by (variable) name, pointer, or even a function such as memcpy().  
> The following example uses a variable name:
> 1st access by first thread
> S1: sharedX = privateA
> 2nd access by second thread
> S2: privateB = sharedX
> If sharedX is a variable visible to all threads and privateA and privateB are local variables visible only to the thread where each was declared,
>  concurrent execution of the above statements by multiple threads results in a "race" on the value to be read from sharedX.   
> Since the order of execution among threads is unpredictable, it is unknown which value will be available in sharedX to be stored into privateB.  
> This results in non-deterministic software, or software prone to produce different results each time it is executed. 
> ____________________________________________________________________
> If it not affect correctness of execution I will mark it by special API for prevention of further alarms on this race.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.