New pthreads-w32 releases available: versions 2.7.0 and 1.11.0

New pthreads-w32 releases available: versions 2.7.0 and 1.11.0

[Ross Johnson]

Announcing two new releases of pthreads-w32:-
pthreads-w32-2-7-0-release
pthreads-w32-1-11-0-release

Packages are available in self-unpacking zip files (.exe) and gzipped
tar files (.tar.gz) as usual.

See
http://sources.redhat.com/pthreads-win32/

or go directly to:
ftp://sources.redhat.com/pub/pthreads-win32/

Red Hat have a low ftp concurrent user limit. Mirrors are at:
http://sources.redhat.com/mirrors.html
(available as they update)


RELEASE 2.7.0 and 1.11.0
------------------------
(2005-06-04)

General
-------
All new features in this release have been back-ported in release 1.11.0,
including the incorporation of MCS locks in pthread_once, however, versions
1 and 2 remain incompatible even though they are now identical in
performance and functionality.

Testing and verification
------------------------
This release has been tested (passed the test suite) on both uni-processor
and multi-processor systems.
- Tim Theisen

Bug fixes
---------
Pthread_once has been re-implemented to remove priority boosting and other
complexity to improve robustness in 2.7.0. Races for Win32 handles that are not
recycle-unique have been removed in 2.7.0. The general form of pthread_once is
now the same as that suggested earlier by Alexander Terekhov, but instead of the
'named mutex', a queue-based lock has been implemented which has the required
properties of dynamic self initialisation and destruction. This lock is also
efficient. The ABI is unaffected in as much as the size of pthread_once_t has
not changed and PTHREAD_ONCE_INIT has not changed, however, applications that
peek inside pthread_once_t, which is supposed to be opaque, will break.
- Vladimir Kliatchko

New features
------------
* Support for Mingw cross development tools added to GNUmakefile.
Mingw cross tools allow building the libraries on Linux.
- Mikael Magnusson

RE: New pthreads-w32 releases available: versions 2.7.0 and 1.11.0

[James Mansion]

Quiet round here - is this still current?

>Announcing two new releases of pthreads-w32:-
>pthreads-w32-2-7-0-release
>pthreads-w32-1-11-0-release

Re: New pthreads-w32 releases available: versions 2.7.0 and 1.11.0

[hanzhu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030; format=flowed, Size: 311 bytes --]

Sure,
We always observe this project!

_______________________________________________________
Best Regards,
hanzhu


James Mansion дµÀ:
> Quiet round here - is this still current?
> 
>> Announcing two new releases of pthreads-w32:-
>> pthreads-w32-2-7-0-release
>> pthreads-w32-1-11-0-release
> 
> 
> 
> 

Re: New pthreads-w32 releases available: versions 2.7.0 and 1.11.0

[Ross Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030; format=flowed, Size: 1636 bytes --]

hanzhu wrote:

> Sure,
> We always observe this project!
>
> _______________________________________________________
> Best Regards,
> hanzhu
>
>
> James Mansion дµÀ:
>
>> Quiet round here - is this still current?
>>
>>> Announcing two new releases of pthreads-w32:-
>>> pthreads-w32-2-7-0-release
>>> pthreads-w32-1-11-0-release
>>
Not sure why I didn't see the OPs message, however ... there have been a 
couple of fairly small changes to the package, but no bug fixes or 
changes that would affect existing applications. Nevertheless, it's 
probably time for another release.

There has been a portability addition that has been placed into CVS:

 From the ChangeLog:
2006-01-25  Prashant Thakre <prashant.thakre at gmail.com>

        * pthread_cancel.c: Added _M_IA64 register context support.

An issue that has been raised, but has not resulted in any changes in 
the code yet, had to do with pthread_barrier_wait(). The following entry 
has been placed in the BUGS file, and a note in the Known Bugs section 
of the relevant manual pages (also in CVS):

4. pthread_barrier_wait() can deadlock if the number of potential calling
threads for a particular barrier is greater than the barrier count parameter
given to pthread_barrier_init() for that barrier.

This is due to the very lightweight implementation of pthread-win32 
barriers.
To cope with more than "count" possible waiters, barriers must effectively
implement all the same safeguards as condition variables, making them much
"heavier" than at present.

The workaround is to ensure that no more than "count" threads attempt to 
wait
at the barrier.

Regards.
Ross