Memory Barriers at pthread using CYGWIN

Memory Barriers at pthread using CYGWIN

[Mümin A.]

[-- 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;
}

RE: [EXTERNAL] Memory Barriers at pthread using CYGWIN

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> result should be
> 
> r1 = 1, r2 = 1
>

And what was the result you saw?

Anton Lavrentiev
Contractor NIH/NLM/NCBI

Re: [EXTERNAL] Memory Barriers at pthread using CYGWIN

[Mümin A.]

[-- 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

Re: [EXTERNAL] Memory Barriers at pthread using CYGWIN

[Kevin Schnitzius]

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

Re: Memory Barriers at pthread using CYGWIN

[Takashi Yano]

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>

Re: Memory Barriers at pthread using CYGWIN

[Duncan Roe]

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.

Re: Memory Barriers at pthread using CYGWIN

[Takashi Yano]

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>

Re: Memory Barriers at pthread using CYGWIN

[Corinna Vinschen]

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

Re: Memory Barriers at pthread using CYGWIN

[Takashi Yano]

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>

Re: Memory Barriers at pthread using CYGWIN

[Takashi Yano]

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>

Re: Memory Barriers at pthread using CYGWIN

[Takashi Yano]

"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>

Re: Memory Barriers at pthread using CYGWIN

[Takashi Yano]

> 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>