* Memory Barriers at pthread using CYGWIN @ 2023-06-08 14:29 Mümin A. 2023-06-08 14:37 ` [EXTERNAL] " Lavrentiev, Anton (NIH/NLM/NCBI) [C] 2023-06-09 1:44 ` Duncan Roe 0 siblings, 2 replies; 12+ messages in thread From: Mümin A. @ 2023-06-08 14:29 UTC (permalink / raw) To: cygwin [-- Attachment #1.1: Type: text/plain, Size: 140 bytes --] Hi, I wrote a simple test for pthread_barrier_wait. it won't work as expected. result should be r1 = 1, r2 = 1 Thanks, Mümin [-- Attachment #2: CMakelists.txt --] [-- Type: text/plain, Size: 295 bytes --] cmake_minimum_required(VERSION 3.26) project(test) set(CMAKE_CXX_STANDARD 14) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CXX_EXTENSIONS OFF) add_definitions(-D__POSIX_VISIBLE=200112 -D_POSIX_C_SOURCE=200112) add_executable(test main.cpp) target_link_libraries(test pthread) [-- Attachment #3: main.cpp --] [-- Type: text/plain, Size: 738 bytes --] #include <stdio.h> #include <pthread.h> int x = 0; int y = 0; int r1 = 0; int r2 = 0; pthread_barrier_t barrier; void* thread1(void* arg) { y = 1; pthread_barrier_wait(&barrier); // Memory barrier r1 = x; return NULL; } void* thread2(void* arg) { x = 1; pthread_barrier_wait(&barrier); // Memory barrier r2 = y; return NULL; } int main() { pthread_t t1, t2; pthread_barrier_init(&barrier, NULL, 2); pthread_create(&t1, NULL, thread1, NULL); pthread_create(&t2, NULL, thread2, NULL); pthread_join(t1, NULL); pthread_join(t2, NULL); printf("r1 = %d, r2 = %d\n", r1, r2); pthread_barrier_destroy(&barrier); return 0; } ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [EXTERNAL] Memory Barriers at pthread using CYGWIN 2023-06-08 14:29 Memory Barriers at pthread using CYGWIN Mümin A. @ 2023-06-08 14:37 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] 2023-06-08 22:58 ` Mümin A. 2023-06-09 1:44 ` Duncan Roe 1 sibling, 1 reply; 12+ messages in thread From: Lavrentiev, Anton (NIH/NLM/NCBI) [C] @ 2023-06-08 14:37 UTC (permalink / raw) To: Mümin A., cygwin > result should be > > r1 = 1, r2 = 1 > And what was the result you saw? Anton Lavrentiev Contractor NIH/NLM/NCBI ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [EXTERNAL] Memory Barriers at pthread using CYGWIN 2023-06-08 14:37 ` [EXTERNAL] " Lavrentiev, Anton (NIH/NLM/NCBI) [C] @ 2023-06-08 22:58 ` Mümin A. 2023-06-09 0:19 ` Kevin Schnitzius 2023-06-09 0:22 ` Takashi Yano 0 siblings, 2 replies; 12+ messages in thread From: Mümin A. @ 2023-06-08 22:58 UTC (permalink / raw) To: Lavrentiev, Anton (NIH/NLM/NCBI) [C], cygwin [-- Attachment #1: Type: text/plain, Size: 653 bytes --] r1=0 and r2=0 That is my result with Cygwin on windows. It’s false. When I compiled with gcc. The result is correct but when I use lasted Cygwin gcc in windows 10. The result is false. Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Lavrentiev, Anton (NIH/NLM/NCBI) [C] <lavr@ncbi.nlm.nih.gov> Sent: Thursday, June 8, 2023 5:37:31 PM To: Mümin A. <muminaydin06@gmail.com>; cygwin@cygwin.com <cygwin@cygwin.com> Subject: RE: [EXTERNAL] Memory Barriers at pthread using CYGWIN > result should be > > r1 = 1, r2 = 1 > And what was the result you saw? Anton Lavrentiev Contractor NIH/NLM/NCBI ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [EXTERNAL] Memory Barriers at pthread using CYGWIN 2023-06-08 22:58 ` Mümin A. @ 2023-06-09 0:19 ` Kevin Schnitzius 2023-06-09 0:22 ` Takashi Yano 1 sibling, 0 replies; 12+ messages in thread From: Kevin Schnitzius @ 2023-06-09 0:19 UTC (permalink / raw) To: cygwin On Thursday, June 8, 2023 at 06:59:53 PM EDT, Mümin A. via Cygwin <cygwin@cygwin.com> wrote: > > r1=0 and r2=0 > That is my result with Cygwin on windows. It’s false. > > When I compiled with gcc. The result is correct but when I use lasted Cygwin gcc in windows 10. The result is false. > cmake . CMake Error at CMakeLists.txt:1 (cmake_minimum_required): CMake 3.26 or higher is required. You are running version 3.25.3 > g++ main.cpp >./a r1 = 1, r2 = 1 Kevin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Memory Barriers at pthread using CYGWIN 2023-06-08 22:58 ` Mümin A. 2023-06-09 0:19 ` Kevin Schnitzius @ 2023-06-09 0:22 ` Takashi Yano 1 sibling, 0 replies; 12+ messages in thread From: Takashi Yano @ 2023-06-09 0:22 UTC (permalink / raw) To: cygwin; +Cc: Mümin A. On Thu, 8 Jun 2023 22:58:59 +0000 Mümin A. wrote: > r1=0 and r2=0 > That is my result with Cygwin on windows. It’s false. > > When I compiled with gcc. The result is correct but when I use lasted Cygwin gcc in windows 10. The result is false. I cannot reproduce your problem. If I compile main.cpp with 'g++ main.cpp', a.exe outputs r1 = 1, r2 = 1 If I use cmake, I get an error message: CMake Error at CMakeLists.txt:1 (cmake_minimum_required): CMake 3.26 or higher is required. You are running version 3.25.3 My environment is: cygwin 3.4.6 g++ (GCC) 11.4.0 cmake version 3.25.3 all packages are updated. -- Takashi Yano <takashi.yano@nifty.ne.jp> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Memory Barriers at pthread using CYGWIN 2023-06-08 14:29 Memory Barriers at pthread using CYGWIN Mümin A. 2023-06-08 14:37 ` [EXTERNAL] " Lavrentiev, Anton (NIH/NLM/NCBI) [C] @ 2023-06-09 1:44 ` Duncan Roe 1 sibling, 0 replies; 12+ messages in thread From: Duncan Roe @ 2023-06-09 1:44 UTC (permalink / raw) To: cygwin On Thu, Jun 08, 2023 at 05:29:59PM +0300, cygwin wrote: > Hi, > > I wrote a simple test for pthread_barrier_wait. it won't work as expected. > > result should be > > r1 = 1, r2 = 1 > > Thanks, > Mümin > cmake_minimum_required(VERSION 3.26) > > project(test) > > set(CMAKE_CXX_STANDARD 14) > set(CMAKE_CXX_STANDARD_REQUIRED ON) > set(CMAKE_CXX_EXTENSIONS OFF) > > > add_definitions(-D__POSIX_VISIBLE=200112 -D_POSIX_C_SOURCE=200112) > > add_executable(test main.cpp) > > target_link_libraries(test pthread) > #include <stdio.h> > #include <pthread.h> > > int x = 0; > int y = 0; > int r1 = 0; > int r2 = 0; > > pthread_barrier_t barrier; > > void* thread1(void* arg) { > y = 1; > pthread_barrier_wait(&barrier); // Memory barrier > r1 = x; > return NULL; > } > > void* thread2(void* arg) { > x = 1; > pthread_barrier_wait(&barrier); // Memory barrier > r2 = y; > return NULL; > } > > int main() { > pthread_t t1, t2; > > pthread_barrier_init(&barrier, NULL, 2); > > pthread_create(&t1, NULL, thread1, NULL); > pthread_create(&t2, NULL, thread2, NULL); > > pthread_join(t1, NULL); > pthread_join(t2, NULL); > > printf("r1 = %d, r2 = %d\n", r1, r2); > > pthread_barrier_destroy(&barrier); > > return 0; > } WFFM (compiled as a C program) Cheers ... Duncan. ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <CAPxKPA6bRfF19pXrYT04TqbxettyYf=ypgfdySysqAJyB9BfxA@mail.gmail.com>]
[parent not found: <CAPxKPA48sKPqwGc-jU7UQvQhsbT0N6A9LJXCAZeaa1rjeRtuNg@mail.gmail.com>]
[parent not found: <96718c68-af84-45a5-9332-337ec4b2f04a@email.android.com>]
* Re: Memory Barriers at pthread using CYGWIN [not found] ` <96718c68-af84-45a5-9332-337ec4b2f04a@email.android.com> @ 2023-06-09 12:25 ` Takashi Yano 0 siblings, 0 replies; 12+ messages in thread From: Takashi Yano @ 2023-06-09 12:25 UTC (permalink / raw) To: M?min A., cygwin > I found a clue. > I'm using cygwin as in windows environment path, C:\cygwin64\bin > > when I open the cygwin terminal , the test is passed but when I close > cygwin terminal and run again the same test exe file then it fails. > > is there any connection about that ? > > The test is valid for native gcc compiler .t1, t2 have valid value. Hmm... Could you please check 'cygcheck ./a.exe' result? Also 'ldd ./a.exe' might help. -- Takashi Yano <takashi.yano@nifty.ne.jp> ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <64831a27.170a0220.1f805.81bfSMTPIN_ADDED_BROKEN@mx.google.com>]
* Re: Memory Barriers at pthread using CYGWIN [not found] ` <64831a27.170a0220.1f805.81bfSMTPIN_ADDED_BROKEN@mx.google.com> @ 2023-06-10 4:08 ` Takashi Yano 2023-06-20 12:53 ` Takashi Yano 0 siblings, 1 reply; 12+ messages in thread From: Takashi Yano @ 2023-06-10 4:08 UTC (permalink / raw) To: cygwin; +Cc: M?min A. "M?min A." wrote: > //windows cmd line > C:\cygwin64\home\maydin\test>cygcheck ./main.exe > C:\cygwin64\home\maydin\test\main.exe > C:\cygwin64\bin\cygwin1.dll > C:\WINDOWS\system32\KERNEL32.dll > C:\WINDOWS\system32\ntdll.dll > C:\WINDOWS\system32\KERNELBASE.dll > > C:\cygwin64\home\maydin\test>ldd ./main.exe > ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffa92350000) > KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL > (0x7ffa90570000) > KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll > (0x7ffa8ffb0000) > cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffa27960000) Looks OK. > //When cygwin terminal closed and cmd line command. Join throw fails. > C:\cygwin64\home\maydin\test>main.exe > Failed to join the thread t1. > Failed to join the thread t2. > r1 = 1, r2 = 1 > > //when cygwin terminal opened. The test is passed. > C:\cygwin64\home\maydin\test>main.exe > r1 = 1, r2 = 1 > > > I think Cygwin terminal should be always open in order to execute a file in > windows. Am I right ? It should not be. Weird enough. Could you please provide a strace log file such as: strace -o faild.log ./main.exe ? -- Takashi Yano <takashi.yano@nifty.ne.jp> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Memory Barriers at pthread using CYGWIN 2023-06-10 4:08 ` Takashi Yano @ 2023-06-20 12:53 ` Takashi Yano 2023-06-22 10:19 ` Takashi Yano 0 siblings, 1 reply; 12+ messages in thread From: Takashi Yano @ 2023-06-20 12:53 UTC (permalink / raw) To: cygwin On Sat, 10 Jun 2023 13:08:04 +0900 (JST) Takashi Yano wrote: > "M?min A." wrote: > > //windows cmd line > > C:\cygwin64\home\maydin\test>cygcheck ./main.exe > > C:\cygwin64\home\maydin\test\main.exe > > C:\cygwin64\bin\cygwin1.dll > > C:\WINDOWS\system32\KERNEL32.dll > > C:\WINDOWS\system32\ntdll.dll > > C:\WINDOWS\system32\KERNELBASE.dll > > > > C:\cygwin64\home\maydin\test>ldd ./main.exe > > ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffa92350000) > > KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL > > (0x7ffa90570000) > > KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll > > (0x7ffa8ffb0000) > > cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffa27960000) > > Looks OK. > > > //When cygwin terminal closed and cmd line command. Join throw fails. > > C:\cygwin64\home\maydin\test>main.exe > > Failed to join the thread t1. > > Failed to join the thread t2. > > r1 = 1, r2 = 1 > > > > //when cygwin terminal opened. The test is passed. > > C:\cygwin64\home\maydin\test>main.exe > > r1 = 1, r2 = 1 > > > > > > I think Cygwin terminal should be always open in order to execute a file in > > windows. Am I right ? > > It should not be. Weird enough. > > Could you please provide a strace log file such as: > strace -o faild.log ./main.exe > ? I looked into this problem, and I think this is a problem regarding _my_tls initialization order, so far. This seems to happen in LDAP environment. My assumption is: If the program is the first program which load cygwin1.dll, ldap connection seems to be made before pthread::init_mainthread(). In cyg_ldap.cc, cyg_ldap::connect(), cyg_ldap::search() or cyg_ldap::next_page() calls cygwait() in which pthread::self() is called. Then, _my_tls.tid is initialized with null_pthread, therefore, _my_tls.tid is not set in pthread::init_mainthread(). This causes pthread_join() failure at: winsup/cygwin/thread.cc: line 2196 if (!is_good_object (&joiner)) return EINVAL; The first idea to fix this issue is remove set_tls_self_pointer() call from pthread::self(). diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc index 5c1284a93..a0f2d5546 100644 --- a/winsup/cygwin/thread.cc +++ b/winsup/cygwin/thread.cc @@ -392,10 +392,7 @@ pthread::self () { pthread *thread = _my_tls.tid; if (!thread) - { - thread = pthread_null::get_null_pthread (); - thread->set_tls_self_pointer (); - } + thread = pthread_null::get_null_pthread (); return thread; } The secnd approach is to re-initialize _my_tls.tid in pthread::init_mainthread() if _my_tls.tid is null_pthread. diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc index 5c1284a93..f614e01c4 100644 --- a/winsup/cygwin/thread.cc +++ b/winsup/cygwin/thread.cc @@ -364,7 +364,7 @@ void pthread::init_mainthread () { pthread *thread = _my_tls.tid; - if (!thread) + if (!thread || thread == pthread_null::get_null_pthread ()) { thread = new pthread (); if (!thread) Which is the better approach, do you think? Or any other idea? -- Takashi Yano <takashi.yano@nifty.ne.jp> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Memory Barriers at pthread using CYGWIN 2023-06-20 12:53 ` Takashi Yano @ 2023-06-22 10:19 ` Takashi Yano 2023-06-22 11:48 ` Corinna Vinschen 0 siblings, 1 reply; 12+ messages in thread From: Takashi Yano @ 2023-06-22 10:19 UTC (permalink / raw) To: cygwin Any suggestions? On Tue, 20 Jun 2023 21:53:00 +0900 Takashi Yano wrote: > On Sat, 10 Jun 2023 13:08:04 +0900 (JST) > Takashi Yano wrote: > > "M?min A." wrote: > > > //windows cmd line > > > C:\cygwin64\home\maydin\test>cygcheck ./main.exe > > > C:\cygwin64\home\maydin\test\main.exe > > > C:\cygwin64\bin\cygwin1.dll > > > C:\WINDOWS\system32\KERNEL32.dll > > > C:\WINDOWS\system32\ntdll.dll > > > C:\WINDOWS\system32\KERNELBASE.dll > > > > > > C:\cygwin64\home\maydin\test>ldd ./main.exe > > > ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffa92350000) > > > KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL > > > (0x7ffa90570000) > > > KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll > > > (0x7ffa8ffb0000) > > > cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffa27960000) > > > > Looks OK. > > > > > //When cygwin terminal closed and cmd line command. Join throw fails. > > > C:\cygwin64\home\maydin\test>main.exe > > > Failed to join the thread t1. > > > Failed to join the thread t2. > > > r1 = 1, r2 = 1 > > > > > > //when cygwin terminal opened. The test is passed. > > > C:\cygwin64\home\maydin\test>main.exe > > > r1 = 1, r2 = 1 > > > > > > > > > I think Cygwin terminal should be always open in order to execute a file in > > > windows. Am I right ? > > > > It should not be. Weird enough. > > > > Could you please provide a strace log file such as: > > strace -o faild.log ./main.exe > > ? > > I looked into this problem, and I think this is a problem regarding > _my_tls initialization order, so far. This seems to happen in LDAP > environment. > > My assumption is: > > If the program is the first program which load cygwin1.dll, ldap > connection seems to be made before pthread::init_mainthread(). > In cyg_ldap.cc, cyg_ldap::connect(), cyg_ldap::search() or > cyg_ldap::next_page() calls cygwait() in which pthread::self() > is called. > > Then, _my_tls.tid is initialized with null_pthread, therefore, > _my_tls.tid is not set in pthread::init_mainthread(). > > This causes pthread_join() failure at: > winsup/cygwin/thread.cc: line 2196 > if (!is_good_object (&joiner)) > return EINVAL; > > > The first idea to fix this issue is remove set_tls_self_pointer() > call from pthread::self(). > > diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc > index 5c1284a93..a0f2d5546 100644 > --- a/winsup/cygwin/thread.cc > +++ b/winsup/cygwin/thread.cc > @@ -392,10 +392,7 @@ pthread::self () > { > pthread *thread = _my_tls.tid; > if (!thread) > - { > - thread = pthread_null::get_null_pthread (); > - thread->set_tls_self_pointer (); > - } > + thread = pthread_null::get_null_pthread (); > return thread; > } > > > The secnd approach is to re-initialize _my_tls.tid in > pthread::init_mainthread() if _my_tls.tid is null_pthread. > > diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc > index 5c1284a93..f614e01c4 100644 > --- a/winsup/cygwin/thread.cc > +++ b/winsup/cygwin/thread.cc > @@ -364,7 +364,7 @@ void > pthread::init_mainthread () > { > pthread *thread = _my_tls.tid; > - if (!thread) > + if (!thread || thread == pthread_null::get_null_pthread ()) > { > thread = new pthread (); > if (!thread) > > > Which is the better approach, do you think? > Or any other idea? -- Takashi Yano <takashi.yano@nifty.ne.jp> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Memory Barriers at pthread using CYGWIN 2023-06-22 10:19 ` Takashi Yano @ 2023-06-22 11:48 ` Corinna Vinschen 2023-06-22 23:49 ` Takashi Yano 0 siblings, 1 reply; 12+ messages in thread From: Corinna Vinschen @ 2023-06-22 11:48 UTC (permalink / raw) To: Takashi Yano; +Cc: cygwin On Jun 22 19:19, Takashi Yano via Cygwin wrote: > Any suggestions? > > On Tue, 20 Jun 2023 21:53:00 +0900 > Takashi Yano wrote: > > I looked into this problem, and I think this is a problem regarding > > _my_tls initialization order, so far. This seems to happen in LDAP > > environment. > > > > My assumption is: > > > > If the program is the first program which load cygwin1.dll, ldap > > connection seems to be made before pthread::init_mainthread(). > > In cyg_ldap.cc, cyg_ldap::connect(), cyg_ldap::search() or > > cyg_ldap::next_page() calls cygwait() in which pthread::self() > > is called. > > > > Then, _my_tls.tid is initialized with null_pthread, therefore, > > _my_tls.tid is not set in pthread::init_mainthread(). > > > > This causes pthread_join() failure at: > > winsup/cygwin/thread.cc: line 2196 > > if (!is_good_object (&joiner)) > > return EINVAL; > > > > > > The first idea to fix this issue is remove set_tls_self_pointer() > > call from pthread::self(). > > > > diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc > > index 5c1284a93..a0f2d5546 100644 > > --- a/winsup/cygwin/thread.cc > > +++ b/winsup/cygwin/thread.cc > > @@ -392,10 +392,7 @@ pthread::self () > > { > > pthread *thread = _my_tls.tid; > > if (!thread) > > - { > > - thread = pthread_null::get_null_pthread (); > > - thread->set_tls_self_pointer (); > > - } > > + thread = pthread_null::get_null_pthread (); > > return thread; > > } > > > > > > The secnd approach is to re-initialize _my_tls.tid in > > pthread::init_mainthread() if _my_tls.tid is null_pthread. > > > > diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc > > index 5c1284a93..f614e01c4 100644 > > --- a/winsup/cygwin/thread.cc > > +++ b/winsup/cygwin/thread.cc > > @@ -364,7 +364,7 @@ void > > pthread::init_mainthread () > > { > > pthread *thread = _my_tls.tid; > > - if (!thread) > > + if (!thread || thread == pthread_null::get_null_pthread ()) > > { > > thread = new pthread (); > > if (!thread) > > > > > > Which is the better approach, do you think? > > Or any other idea? The second approach looks good to me. There was a reason to call set_tls_self_pointer from pthread::self, I guess. Resetting in init_mainthread should have the least potential for side-effects. Thanks, Corinna ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Memory Barriers at pthread using CYGWIN 2023-06-22 11:48 ` Corinna Vinschen @ 2023-06-22 23:49 ` Takashi Yano 0 siblings, 0 replies; 12+ messages in thread From: Takashi Yano @ 2023-06-22 23:49 UTC (permalink / raw) To: cygwin On Thu, 22 Jun 2023 13:48:53 +0200 Corinna Vinschen wrote: > On Jun 22 19:19, Takashi Yano via Cygwin wrote: > > Any suggestions? > > > > On Tue, 20 Jun 2023 21:53:00 +0900 > > Takashi Yano wrote: > > > I looked into this problem, and I think this is a problem regarding > > > _my_tls initialization order, so far. This seems to happen in LDAP > > > environment. > > > > > > My assumption is: > > > > > > If the program is the first program which load cygwin1.dll, ldap > > > connection seems to be made before pthread::init_mainthread(). > > > In cyg_ldap.cc, cyg_ldap::connect(), cyg_ldap::search() or > > > cyg_ldap::next_page() calls cygwait() in which pthread::self() > > > is called. > > > > > > Then, _my_tls.tid is initialized with null_pthread, therefore, > > > _my_tls.tid is not set in pthread::init_mainthread(). > > > > > > This causes pthread_join() failure at: > > > winsup/cygwin/thread.cc: line 2196 > > > if (!is_good_object (&joiner)) > > > return EINVAL; > > > > > > > > > The first idea to fix this issue is remove set_tls_self_pointer() > > > call from pthread::self(). > > > > > > diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc > > > index 5c1284a93..a0f2d5546 100644 > > > --- a/winsup/cygwin/thread.cc > > > +++ b/winsup/cygwin/thread.cc > > > @@ -392,10 +392,7 @@ pthread::self () > > > { > > > pthread *thread = _my_tls.tid; > > > if (!thread) > > > - { > > > - thread = pthread_null::get_null_pthread (); > > > - thread->set_tls_self_pointer (); > > > - } > > > + thread = pthread_null::get_null_pthread (); > > > return thread; > > > } > > > > > > > > > The secnd approach is to re-initialize _my_tls.tid in > > > pthread::init_mainthread() if _my_tls.tid is null_pthread. > > > > > > diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc > > > index 5c1284a93..f614e01c4 100644 > > > --- a/winsup/cygwin/thread.cc > > > +++ b/winsup/cygwin/thread.cc > > > @@ -364,7 +364,7 @@ void > > > pthread::init_mainthread () > > > { > > > pthread *thread = _my_tls.tid; > > > - if (!thread) > > > + if (!thread || thread == pthread_null::get_null_pthread ()) > > > { > > > thread = new pthread (); > > > if (!thread) > > > > > > > > > Which is the better approach, do you think? > > > Or any other idea? > > The second approach looks good to me. There was a reason to call > set_tls_self_pointer from pthread::self, I guess. Resetting in > init_mainthread should have the least potential for side-effects. Thanks. I submitted the patch to cygwin-patches@cygwin.com. Please let me know if I can push it. -- Takashi Yano <takashi.yano@nifty.ne.jp> ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-06-22 23:49 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-06-08 14:29 Memory Barriers at pthread using CYGWIN Mümin A. 2023-06-08 14:37 ` [EXTERNAL] " Lavrentiev, Anton (NIH/NLM/NCBI) [C] 2023-06-08 22:58 ` Mümin A. 2023-06-09 0:19 ` Kevin Schnitzius 2023-06-09 0:22 ` Takashi Yano 2023-06-09 1:44 ` Duncan Roe [not found] <CAPxKPA6bRfF19pXrYT04TqbxettyYf=ypgfdySysqAJyB9BfxA@mail.gmail.com> [not found] ` <CAPxKPA48sKPqwGc-jU7UQvQhsbT0N6A9LJXCAZeaa1rjeRtuNg@mail.gmail.com> [not found] ` <96718c68-af84-45a5-9332-337ec4b2f04a@email.android.com> 2023-06-09 12:25 ` Takashi Yano [not found] ` <64831a27.170a0220.1f805.81bfSMTPIN_ADDED_BROKEN@mx.google.com> 2023-06-10 4:08 ` Takashi Yano 2023-06-20 12:53 ` Takashi Yano 2023-06-22 10:19 ` Takashi Yano 2023-06-22 11:48 ` Corinna Vinschen 2023-06-22 23:49 ` Takashi Yano
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).