RE: semaphores

RE: semaphores

[Bossom, John]

[-- Attachment #1: Type: text/plain, Size: 2295 bytes --]

sem_getvalue()? 
 
I don't see that in the standard (POSIX.1b (POSIX 1003.1b-1993))... I assume
this
has been added to the pthreads-win32 implementation as an extension (Ross?)
 
Perhaps there is a bug in that new method.
 
However, try looping over sem_trywait and count the # of times it returns 0.
It should return EAGAIN
when the semaphore count is zero.
 
Sorry, I can't help you with the sem_getvalue....
 
Note that since the sem_ calls are from an earlier standard, that when they
fail they are supposed
to return -1 and set errno to the actual error number....
 
John.

-----Original Message-----
From: Rob Fanner [mailto:rfanner@stonethree.com]
Sent: May 30, 2002 10:10 AM
To: pthreads-win32@sources.redhat.com
Subject: semaphores


I'm new to using pthreads-win32 (SNAPSHOT 2002-03-02), and I have to port 
a program from Linux to Windows 2000. A bug has somehow crept into my 
code, and I've narrowed the problem area down to a code fragment similar 
to the following:
 
#include <semaphore.h>
#include <cassert>
#include <iostream>
 
using namespace std;
 
int main()
{
   /**
    * We want to check wether a semaphore can be initialised
    * with a value.
    */
   
   // a semaphore
   sem_t psem;
 
   // initialise it with value 10
   assert(sem_init(&psem,0,10) == 0);                       // ASSERT NO 1
   // if the semaphore initialisation was ok, the sem
   // should now have the value 10
   int ret = 0;
   assert(sem_getvalue(&psem,&ret) == 0);               // ASSERT NO 2
   // if no errors occured then value is now in the 
   // integer ret
   cout << endl << "sem_getvalue() returns value " << ret << endl << flush;
 
   return 0;
}
 
I'm using MS VC++ 6.0, and I'm linking with the precompiled pthreadVCE.lib
library.
At runtime, the first assert() passes OK, but second fails.
I have no idea why this fails (hopefully it's simply a newby error, and not
a bug in 
the pthreads-win32 lib), but it does.
 
Thanks
Rob


This message may contain privileged and/or confidential information.  If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.  Thank you.

[-- Attachment #2: Type: text/html, Size: 5750 bytes --]

Re: semaphores

[Phil Frisbie, Jr.]

It is included in the The Single UNIX ® Specification, Version 2.

http://www.opengroup.org/onlinepubs/7908799/xsh/sem_getvalue.html


Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

Re: semaphores

[Rob Fanner]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

Thanks for the advice. There is one error in the 
original code frag, though:
(taken from the Linux threads man pages)
The sem_wait and sem_getvalue functions always return 0. 
So, the assert() on sem_getvalue() should always have worked,
under the linux threads documentation.

pthreads-win32, however, seems to return -1 on failure (which
is ok for the code frag) 

if ( result != 0 )
    {
      errno = result;
      return -1;
    }
 
However, this indicates that the sem_getvalue() implementation in pthreads-win32, or my compilation, is not quite as it should be.

Thanks to J Bossom for his suggestion. The following fragment 
compiles and runs just fine:

#include <semaphore.h>
#include <cassert>
#include <iostream>

using namespace std;

int main()
{
   /**
    * We want to check wether a semaphore can be initialised
    * with a value.
    */
   
   // a semaphore
   sem_t psem;

   // initialise it with value 10
   assert(sem_init(&psem,0,10) == 0);
   // if the semaphore initialisation was ok, the sem
   // should now have the value 10

   // trying out J Bossom's idea of counting down
   // using a trywait
   int cnt=0;
   while (sem_trywait(&psem)==0) cnt++;
   cout << "Final value of cnt is " << cnt << endl << flush;
 
   return 0;
}

This indicates that the sem_init() and sem_trywait(), functions
are OK.


[-- Attachment #2: Type: text/html, Size: 3143 bytes --]

Re: semaphores

[Rob Fanner]

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

I've found the problem. It looks like the
pthreads-win32 coders already know about it, as
it is commented in the set_getvalue.c source file:


      /* Note:
       *  The windows NT documentation says that the increment must be
       *  greater than zero, but it is set to zero here. If this works,
       *  the function will return true. If not, we can't do it this way
       *  so flag it as not implemented.
       */

It has to do with the differences between the Win98
and Win NT implementation of the function 
ReleaseSemaphore(). For the record, I ran the same piece of 
code on 98 and NT platforms, and the sem_getvalue() function
does *not* work on NT (*as was suspected).

Thanks again everyone
Rob

[-- Attachment #2: Type: text/html, Size: 1749 bytes --]

Re: semaphores

[Ross Johnson]

Hi John/Rob,

Bossom, John wrote:
> sem_getvalue()?
> 
> I don't see that in the standard (POSIX.1b (POSIX 1003.1b-1993))... I 
> assume this has been added to the pthreads-win32 implementation
 > as an extension (Ross?)

This function is noted by the contributor in the ChangeLog as a 
'trial' version. It appears to be defined according to the Single 
Unix Specification version 2 (as noted by other respondents):-

http://www.opengroup.org/onlinepubs/7908799/xsh/sem_getvalue.html

This definition is different to the latest POSIX standard IEEE Std 
1003.1-200x (I'm looking at draft 7), which removes ENOSYS from the 
list of returnable errors for this function. I don't know if that 
means that it must not return ENOSYS.

> 
> Perhaps there is a bug in that new method.
> 

The following comment and code is pretty much all there is to the 
function:

/* Note:
  *  The windows NT documentation says that the increment must be
  *  greater than zero, but it is set to zero here. If this works,
  *  the function will return true. If not, we can't do it this way
  *  so flag it as not implemented.
  */
       if ( ReleaseSemaphore( (*sem)->sem, 0L, &value) )
         {
           *sval = value;
         }
       else
         {
           result = ENOSYS;
         }

There's no test in the current test suite for this routine (will do 
though). And the routine would seem to need to be rewritten.

Regards.
Ross

>  
> 
> However, try looping over sem_trywait and count the # of times it 
> returns 0. It should return EAGAIN
> 
> when the semaphore count is zero.
> 
>  
> 
> Sorry, I can't help you with the sem_getvalue....
> 
>  
> 
> Note that since the sem_ calls are from an earlier standard, that when 
> they fail they are supposed
> 
> to return -1 and set errno to the actual error number....
> 
>  
> 
> John.
> 
>     -----Original Message-----
>     *From:* Rob Fanner [mailto:rfanner@stonethree.com]
>     *Sent:* May 30, 2002 10:10 AM
>     *To:* pthreads-win32@sources.redhat.com
>     *Subject:* semaphores
> 
>     I'm new to using pthreads-win32 (SNAPSHOT 2002-03-02), and I have to
>     port 
> 
>     a program from Linux to Windows 2000. A bug has somehow crept into my
> 
>     code, and I've narrowed the problem area down to a code fragment
>     similar
> 
>     to the following:
> 
>      
> 
>     #include <semaphore.h>
>     #include <cassert>
>     #include <iostream>
> 
>      
> 
>     using namespace std;
> 
>      
> 
>     int main()
>     {
>        /**
>         * We want to check wether a semaphore can be initialised
>         * with a value.
>         */
>       
>        // a semaphore
>        sem_t psem;
> 
>      
> 
>        // initialise it with value 10
>        assert(sem_init(&psem,0,10) == 0);                       //
>     ASSERT NO 1
>        // if the semaphore initialisation was ok, the sem
>        // should now have the value 10
>        int ret = 0;
>        assert(sem_getvalue(&psem,&ret) == 0);               // ASSERT NO 2
>        // if no errors occured then value is now in the
>        // integer ret
>        cout << endl << "sem_getvalue() returns value " << ret << endl <<
>     flush;
>      
>        return 0;
>     }
> 
>      
> 
>     I'm using MS VC++ 6.0, and I'm linking with the precompiled
>     pthreadVCE.lib library.
> 
>     At runtime, the first assert() passes OK, but second fails.
> 
>     I have no idea why this fails (hopefully it's simply a newby error,
>     and not a bug in
> 
>     the pthreads-win32 lib), but it does.
> 
>      
> 
>     Thanks
> 
>     Rob
> 
> 
> This message may contain privileged and/or confidential information. If 
> you have received this e-mail in error or are not the intended 
> recipient, you may not use, copy, disseminate or distribute it; do not 
> open any attachments, delete it immediately from your system and notify 
> the sender promptly by e-mail that you have done so. Thank you.
> 


-- 
+-------------------------+---+
| Ross Johnson            |   | "Come down off the cross
| Management & Technology |___|  We can use the wood" - Tom Waits
| Building 11                 |
| University of Canberra      | eMail: rpj@ise.canberra.edu.au
| ACT    2601                 | WWW: 
http://public.ise.canberra.edu.au/~rpj/
| AUSTRALIA                   |
+-----------------------------+

Re: semaphores

[Rob Fanner]

Ross wrote:

> Hi John/Rob,
>
> Bossom, John wrote:
> > sem_getvalue()?
> >

> There's no test in the current test suite for this routine (will do
> though). And the routine would seem to need to be rewritten.
>
> Regards.
> Ross

Thanks Ross. I've thought of one or two workarounds (which mostly
involve using ReleaseSemaphore(semhandle,1,previouscount) followed by a
trywait to solve the NT problem of not being able
to do a ReleaseSemaphore with a 0 releasecount.

However, a more elegant solution --- closer to the original intent --- could
be to exploit the following, taken from "Win32 System Programming
Second Edition" by Johnson M Hart, chapter 9, page 256 :

"The release count must be greater than zero, but if it would cause the
semaphore count to exceed the maximum, the call will fail, returning FALSE,
and the count will remain unchanged.
Releasing a semaphore with a large count is a method used to obtain the
current count atomically (of course, another
thread might change the value immediately)."

So instead of

     if ( ReleaseSemaphore( (*sem)->sem, 0L, &value) )
        {
          *sval = value;
        }

this might be a good alternative

     if ( ReleaseSemaphore( (*sem)->sem, GREATER_THAN_MAXIMUM_SEM_VALUE,
&value) )
        {
          *sval = value;
        }

Sorry that I've not hacked this into the source and sent you a correct
patch, but I'm still not confident with VC++ builds, and
I'm still a bit clueless as to how to set up a pthreadVCE.lib (which I need)
as opposed to a pthreadVC.lib (the standard
build for the distro's .dsp file).

OK. Thanks again for all the advice. It is really appreciated.

Rob

Re: semaphores

[Ross Johnson]

Rob Fanner wrote:
> this might be a good alternative
> 
>      if ( ReleaseSemaphore( (*sem)->sem, GREATER_THAN_MAXIMUM_SEM_VALUE,
> &value) )
>         {
>           *sval = value;
>         }
> 
> Sorry that I've not hacked this into the source and sent you a correct
> patch, but I'm still not confident with VC++ builds, and
> I'm still a bit clueless as to how to set up a pthreadVCE.lib (which I need)
> as opposed to a pthreadVC.lib (the standard
> build for the distro's .dsp file).

Great! Unless there are any problems with this, it will go into the 
next snapshot.

Re pthreadVCE.lib, if you've built the pthreadVC.lib version 
successfully using the .dsp file, you should only need to add the 
following compiler flags:-

/GX /TP /D__CLEANUP_CXX

to build pthreadVCE.lib/.dll (and change the names of your output 
files of course). I don't recall off-hand what /TP does, but it's 
included with the other flags in the Makefile. This is what I use 
for the pre-built libs.

If you're using pthreadVCE.lib then you should also be defining 
__CLEANUP_CXX for your application build, so that the appropriate 
sections of pthread.h are included.

You may be interested in reading Q4 and Q5 in the pthreads-win32 FAQ 
file at:-

ftp://sources.redhat.com/pub/pthreads-win32/FAQ

or the section "SNAPSHOT 2002-03-02 / Cleanup code default style" at:-

http://sources.redhat.com/pthreads-win32/news.html

This will explain why the build defaults to pthreadVC. For 
additional information, the problems/issues have been discussed on 
the mailing list a couple of times, the most recent thread starts at:-

http://sources.redhat.com/ml/pthreads-win32/2001/msg00143.html

Regards.
Ross

Semaphores

[Platzer Wolfgang]

Hi,

here is a link to a code that shows how to use an undocumented Win32 API call to query the value of a semaphore: http://www.codeguru.com/win32/querysem.shtml

It works fine for WinNT, Win2000 and WindowsXP!

regards,

wolfgang

RE: semaphores

[Nicolas EDEL]

Isn't it POSIX 1003.1 , but Realtime Extensions ?


> -----Message d'origine-----
> De : Phil Frisbie, Jr. [mailto:phil@hawksoft.com]
> Envoyé : jeudi 30 mai 2002 17:34
> À : Bossom, John
> Cc : 'Rob Fanner'; pthreads-win32@sources.redhat.com
> Objet : Re: semaphores
> 
> 
> It is included in the The Single UNIX ® Specification, Version 2.
> 
> http://www.opengroup.org/onlinepubs/7908799/xsh/sem_getvalue.html
> 
> 
> Phil Frisbie, Jr.
> Hawk Software
> http://www.hawksoft.com
> 

> -----Message d'origine-----
> De : Phil Frisbie, Jr. [mailto:phil@hawksoft.com]
> Envoyé : jeudi 30 mai 2002 17:34
> À : Bossom, John
> Cc : 'Rob Fanner'; pthreads-win32@sources.redhat.com
> Objet : Re: semaphores
> 
> 
> It is included in the The Single UNIX ® Specification, Version 2.
> 
> http://www.opengroup.org/onlinepubs/7908799/xsh/sem_getvalue.html
> 
> 
> Phil Frisbie, Jr.
> Hawk Software
> http://www.hawksoft.com
> 

semaphores

[Rob Fanner]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

I'm new to using pthreads-win32 (SNAPSHOT 2002-03-02), and I have to port 
a program from Linux to Windows 2000. A bug has somehow crept into my 
code, and I've narrowed the problem area down to a code fragment similar 
to the following:

#include <semaphore.h>
#include <cassert>
#include <iostream>

using namespace std;

int main()
{
   /**
    * We want to check wether a semaphore can be initialised
    * with a value.
    */
   
   // a semaphore
   sem_t psem;

   // initialise it with value 10
   assert(sem_init(&psem,0,10) == 0);                       // ASSERT NO 1
   // if the semaphore initialisation was ok, the sem
   // should now have the value 10
   int ret = 0;
   assert(sem_getvalue(&psem,&ret) == 0);               // ASSERT NO 2
   // if no errors occured then value is now in the 
   // integer ret
   cout << endl << "sem_getvalue() returns value " << ret << endl << flush;
 
   return 0;
}

I'm using MS VC++ 6.0, and I'm linking with the precompiled pthreadVCE.lib library.
At runtime, the first assert() passes OK, but second fails.
I have no idea why this fails (hopefully it's simply a newby error, and not a bug in 
the pthreads-win32 lib), but it does.

Thanks
Rob

[-- Attachment #2: Type: text/html, Size: 2813 bytes --]

Re: semaphores

[Ross Johnson]

On Tue, 20 Apr 1999, Michael Ambrus wrote:

> Hi,
> I've tried the new semaphores and they seem to work fine except that errno
> is not properly set as Ross said.

Are you using the 1999-04-07 snapshot? Anything before that should
be upgraded. Can you provide me with some code that illustrates the
problem? The simple test I wrote (tests/errno1.c in the source tree)
checks that two threads can set and retrieve values of errno
independently. The test succeeds for MSVC (tested on WinNT) and
Mingw32 (tested on Win98).

> I'm confused about the "pshared" attribute
> though. Should it not be != 0 if the semaphore is to be shared between
> processes/treads ?

pshared should be non-zero for shared semaphores, however,
pthreads-win32 doesn't yet support any process shared objects. So
sem_init should return EPERM if you set pshared != 0.

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

semaphores

[Michael Ambrus]

Hi,
I've tried the new semaphores and they seem to work fine except that errno
is not properly set as Ross said. I'm confused about the "pshared" attribute
though. Should it not be != 0 if the semaphore is to be shared between
processes/treads ?

W.k.r.
Michael Ambrus