[PTHREADS]: Mailing List Details

[PTHREADS]: Mailing List Details

[Ross Johnson]

Hi all,

As was announced recently, this list has moved to a new address:

	pthreads-win32@sourceware.cygnus.com

If you're reading this now, it means that you are already subscribed
to the new list. This also means that the message you received when
you originally subscribed is probably irrelevant as the list server
software has also changed. So this message is intended to provide
you with a few details that you may find useful:

------------------------
PLEASE SAVE THIS MESSAGE
------------------------

Unsubscribing
-------------
(just going on vacation? that is, where your subscribed address ==
your current address)

Just send a message to:-

	pthreads-win32-unsubscribe@sourceware.cygnus.com

The subject and message body are ignored.


Unsubscribing
-------------
(got a new job? that is, where your subscribed address != your
current address, but you can still read mail via the old address)

Send a message to:-

	pthreads-win32-unsubscribe-USER=OLD.DOM@sourceware.cygnus.com

where:	USER is your old user name
	OLD.DOM is your old host.domain address

Note the use of '=' in place of '@' for the old address.

A confirmation message will be sent to USER@OLD.DOM (which is
hopefully being forwarded to your new address). Responding to it
will remove the old address from the list.


Subscribing
-----------

Just send a message to:-

	pthreads-win32-subscribe@sourceware.cygnus.com

The subject and body of your message will be ignored.

Reply to the confirmation message when you get it.


Getting info
------------

Send a message to:-

	pthreads-win32-info@sourceware.cygnus.com

Will send you a reply containing any list specific info, as well as
some more help describing list commands, eg. how to get archived
list messages. (Note that messages sent to the list prior to the
move were not archived.)


Thanks.
Ross

+----------------------+---+
| Ross Johnson         |   | E-Mail: rpj@ise.canberra.edu.au
| Info Sciences and Eng|___|
| University of Canberra   | FAX:    +61 6 2015227
| PO Box 1                 |
| Belconnen  ACT    2616   | WWW:    http://willow.canberra.edu.au/~rpj/
| AUSTRALIA                |
+--------------------------+

Still having deadlock problems ?

[Pietrobon Marcello]

At the end of  the page http://sources.redhat.com/pthreads-win32/
there is a link to an important article of  Johnson M. Hart with title
"Experiments with the Open Source Pthreads Library and Some Comments"
(http://world.std.com/~jmhart/opensource.htm).

In the middle of that article he talks really well about Open Source POSIX
Threads for Win32, but he also says:
"Furthermore, the Open Source code contains at least one comment about a
possible deadlock; this comment is not very reassuring."

What is talking about. Is still that problem existing ?
It is very important to me to be able to trust completely Pthread-Win32, so
I cannot use it if I don't know when this problem appears.

If this problem does not appears, it would be a good idea to ask J. M. Hart
to update that statement in his article.

Best Regards,
Marcello

Re: Still having deadlock problems ?

[Ross Johnson]

Pietrobon Marcello wrote:
> 
> At the end of  the page http://sources.redhat.com/pthreads-win32/
> there is a link to an important article of  Johnson M. Hart with title
> "Experiments with the Open Source Pthreads Library and Some Comments"
> (http://world.std.com/~jmhart/opensource.htm).
> 
> In the middle of that article he talks really well about Open Source POSIX
> Threads for Win32, but he also says:
> "Furthermore, the Open Source code contains at least one comment about a
> possible deadlock; this comment is not very reassuring."
> 
> What is talking about. Is still that problem existing ?

I think he's refering to a comment in mutex.c in the function
pthread_mutex_destroy():

          /*
           * FIXME!!!
           * The mutex isn't held by another thread but we could still
           * be too late invalidating the mutex below since another
thread
           * may already have entered mutex_lock and the check for a
valid
           * *mutex != NULL.
           */

NULL is used to indicate an invalid mutex. It still exists,
probably because to fix it would slow mutexes down with
extra checking.

This is the only known race condition in the code, and many
keen eyes have looked through it. If there were others
they would have been commented too.

> It is very important to me to be able to trust completely Pthread-Win32, so
> I cannot use it if I don't know when this problem appears.

To the extent that you can trust any library completely, you
can trust pthreads-win32 to do an excellent job.

Having said that, please check the Conformance section
of the ANNOUNCE file before you make your final decision.

If you decide to use it, there will be a new snapshot
out soon with a few bug fixes and enhancements. You can
grab the very latest development sources from the CVS
repository by following the instructions on the
pthreads-win32 web page.

Ross

Re: Still having deadlock problems ?

[Pietrobon Marcello]

Thank you for all your quick answers.
You convinced me completely.

I agree that this problem has to have a low priority. It my be not cost effective
to resolve it, though.
But the pthread-win32 library would gain a lot of consideration if this minor
error would be fixed.
Let me know if you do it. I will write then to  Johnson M. Hart  to change what
he wrote, even if I think it would be more effective if you ask him to do it.

Best Regards,
Marcello

Ross Johnson wrote:

> Pietrobon Marcello wrote:
> >
> > At the end of  the page http://sources.redhat.com/pthreads-win32/
> > there is a link to an important article of  Johnson M. Hart with title
> > "Experiments with the Open Source Pthreads Library and Some Comments"
> > (http://world.std.com/~jmhart/opensource.htm).
> >
> > In the middle of that article he talks really well about Open Source POSIX
> > Threads for Win32, but he also says:
> > "Furthermore, the Open Source code contains at least one comment about a
> > possible deadlock; this comment is not very reassuring."
> >
> > What is talking about. Is still that problem existing ?
>
> I think he's refering to a comment in mutex.c in the function
> pthread_mutex_destroy():
>
>           /*
>            * FIXME!!!
>            * The mutex isn't held by another thread but we could still
>            * be too late invalidating the mutex below since another
> thread
>            * may already have entered mutex_lock and the check for a
> valid
>            * *mutex != NULL.
>            */
>
> NULL is used to indicate an invalid mutex. It still exists,
> probably because to fix it would slow mutexes down with
> extra checking.
>
> This is the only known race condition in the code, and many
> keen eyes have looked through it. If there were others
> they would have been commented too.
>
> > It is very important to me to be able to trust completely Pthread-Win32, so
> > I cannot use it if I don't know when this problem appears.
>
> To the extent that you can trust any library completely, you
> can trust pthreads-win32 to do an excellent job.
>
> Having said that, please check the Conformance section
> of the ANNOUNCE file before you make your final decision.
>
> If you decide to use it, there will be a new snapshot
> out soon with a few bug fixes and enhancements. You can
> grab the very latest development sources from the CVS
> repository by following the instructions on the
> pthreads-win32 web page.
>
> Ross