Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82
Hi Takashi Yano,
> The result is as follows (submitted as v4 patch).
>
> int
> pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
> {
> /* Sign bit of once_control->state is used as done flag.
> Similary, the next significant bit is used as destroyed flag. */
> const int done = INT_MIN; /* 0b1000 */
> const int destroyed = INT_MIN >> 1; /* 0b1100 */
> if (once_control->state & done)
> return 0;
>
> /* The type of &once_control->state is int *, which is compatible with
> LONG * (the type of the pointer argument of InterlockedXxx()). */
> if ((InterlockedIncrement (&once_control->state) & done) == 0)
> {
> pthread_mutex_lock (&once_control->mutex);
> if (!(once_control->state & done))
> {
> init_routine ();
> InterlockedOr (&once_control->state, done);
> }
> pthread_mutex_unlock (&once_control->mutex);
> }
> InterlockedDecrement (&once_control->state);
> if (InterlockedCompareExchange (&once_control->state,
> destroyed, done) == done)
> pthread_mutex_destroy (&once_control->mutex);
> return 0;
> }
> ...
> I believe both codes are equivalent. Could you please check?
Yes, they are equivalent. This code is free of race conditions. (Let's
hope I am not making a mistake again.)
For legibility I would write the constant values as bit masks:
0x8000
0xc000
and - following the habit that constant integers should have names in
upper case - I would rename
done → DONE
destroyed → DESTROYED
Bruno
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82
On Sun, 02 Jun 2024 15:14:51 +0200
Bruno Haible wrote:
> Hi Takashi Yano,
>
> > The result is as follows (submitted as v4 patch).
> >
> > int
> > pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
> > {
> > /* Sign bit of once_control->state is used as done flag.
> > Similary, the next significant bit is used as destroyed flag. */
> > const int done = INT_MIN; /* 0b1000 */
> > const int destroyed = INT_MIN >> 1; /* 0b1100 */
> > if (once_control->state & done)
> > return 0;
> >
> > /* The type of &once_control->state is int *, which is compatible with
> > LONG * (the type of the pointer argument of InterlockedXxx()). */
> > if ((InterlockedIncrement (&once_control->state) & done) == 0)
> > {
> > pthread_mutex_lock (&once_control->mutex);
> > if (!(once_control->state & done))
> > {
> > init_routine ();
> > InterlockedOr (&once_control->state, done);
> > }
> > pthread_mutex_unlock (&once_control->mutex);
> > }
> > InterlockedDecrement (&once_control->state);
> > if (InterlockedCompareExchange (&once_control->state,
> > destroyed, done) == done)
> > pthread_mutex_destroy (&once_control->mutex);
> > return 0;
> > }
> > ...
> > I believe both codes are equivalent. Could you please check?
>
> Yes, they are equivalent. This code is free of race conditions. (Let's
> hope I am not making a mistake again.)
>
> For legibility I would write the constant values as bit masks:
> 0x8000
> 0xc000
> and - following the habit that constant integers should have names in
> upper case - I would rename
> done → DONE
> destroyed → DESTROYED
Thanks for checking. I'll push the patch after the modification.
--
Takashi Yano
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: newer version of mingw64-*-win-iconv ?
On 29/05/2024 07:58, Brian Inglis via Cygwin wrote: On 2024-05-28 19:12, Bruno Haible via Cygwin wrote: It would be useful if someone could rebuild the two packages https://cygwin.com/packages/summary/mingw64-i686-win-iconv.html https://cygwin.com/packages/summary/mingw64-x86_64-win-iconv.html based off the current git HEAD [1]. Reason: The current git HEAD is a reasonable alternative to GNU libiconv; all encodings that it supports, other than EUC-JP and GB18030, have reasonably good conversion tables. Wherease the current Cygwin packages are based off source code from 2013 and have a major problem already with the ASCII encoding. [1] https://github.com/win-iconv/win-iconv Ran playground local and CI builds of these packages at v0.0.8 successfully: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv Do we really need the fix at git HEAD to add UCS-2-INTERNAL encoding? Could someone please do any further tweaks for this source git if required, and do NMU builds and deploys of these? I've given you NMU privileges, so now that someone can be you! [Are we really still building 32 bit mingw packages when we dropped support of 32 bit Windows << 1%? There's a difference between "we don't support running on 32-bit Windows" and "We don't support cross-compiling to 32-bit Windows". Now, I'd like to do this in an evidence based manner e.g. if we had some statistics on packages that cygwin users choose to install, and hardly anyone was bothering with mingw 32-bit packages, then dropping them would be a good way of conserving our very limited maintainer resource. But as previously observed, that depends on building something to collect that data, which SHTDI. (There's also some unfinished work by Yaakov in a branch of the cygport repo which enhances cross-compile support, so that a single source package can produce mingw-cross install packages for multiple architectures, which would make it easier to continue to support these packages, and/or drop them in future, and/or add mingw arm64 cross-packages when the toolchain for them exists...) -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Plans to update meson version?
On 01/06/2024 16:24, Dave Trombley via Cygwin wrote: Meson appears to be two majore versions behind in cygwin (1.2.3 is latest available, 1.4.0 was released mid-March this year). Major projects are starting to not be compilable on Cygwin, consequently, short of manually building a custom meson that is up to date (for example, libcairo requires 1.3). Are there plans to update this at some point? The "plan" is "when I get around to it" Thanks for the reminder, though. It seems I overlooked meson 1.3.x, so I've updated the package today. (I don't usually package 1.n.x until 1.n+1.0 is available, because historically .0 releases of meson have had a high chance of containing regressions, although things are better these days...) -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [Ms-nfs41-client-devel] WinSG Re: ANN: NFSv4.1 filesystem client Windows driver binaries for Windows 10/11 for testing, 2024-05-28 ...
>> - WinSG should be installed in C:\Windows\system32\ alongside cmd.exe > >Not yet, all stuff for the Cygwin install of the ms-nfs41-client goes >into the Cygwin /bin && /sbin dirs. Let's try for NEVER. 3rd parties have no business polluting the operating system. If this is MS code or closely related to it, then it properly belongs in /usr/local or more correctly /opt as it's not part of Cygwin proper either, correct? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
