Re: posix mutex vs win32 mutex. was why linux?

On Mon, 6 Oct 2003, Steve Richter wrote:
>
> "The pthread_lock_global_np() function locks a global mutex provided by the
> pthreads run-time. The global mutex is a recursive mutex with a name of
> "QP0W_GLOBAL_MTX". The global mutex is not currently used by the pthreads
> run-time to serialize access to any system resources, and is provided for
> application use only."

Okay.  The "_np()" at the end of the function name stands for "not
portable."   My experiences with mutexes is somewhat limited, but I've
done code like this:

      pthread_attr_t mymutex = PTHREAD_MUTEX_INITIALIZER;

      void function() {
           pthread_mutex_lock(&mymutex);
         ... access the protected variable here ...
           pthread_mutex_unlock(&mymutex);
      }


> The WIN32 way is for the programmer to assign a long, unique name to the
> mutex.  The OS400 way is to ALCOBJ an object in a library.  The MI way is to
> LOCKSL ( lock space location ) on a space object in a library.

To me pthread differs quite a bit from ALCOBJ!  ALCOBJ is to block access
to a database for completely independent programs on the system...
Whereas pthread is designed for multiple threads all started from the same
job, and sharing memory...

> When different jobs refer to the same mutex to lock the same resource (
> sharing a socket port or writing to the end of an IFS text file ), how is
> the unique 4 byte, system assigned, identifier known by all of those jobs?
> What is the POSIX way?

Passing the ID from process to process isn't necessary, since it's in
shared memory.

I wasn't aware that the pthread APIs could be used to lock things other
than memory shared by different threads.  Though, granted, I don't have a
lot of exposure to mutexes...

If I wanted to lock a text file, I'd (strangely enough) use the file
locking APIs.  fcntl() (with F_SETLK) is the POSIX way of doing this, but
BSD systems (possibly others?) also have flock() which is a somewhat nicer
API.  Unlike mutexes, the file locking APIs can do both "exclusive locks"
and "shared locks"  which allow multiple processes to lock the same
object.

I think the file locking APIs are far more like ALCOBJ than the mutex
APIs.

>
> ( BTW, the OS400 way has advantages over the WIN32 way.  With the library in
> the mix, the application can easily be run in TEST and PROD environments.
> ( Library name is different ).  To make the WIN32 mutex name unique to a
> PROD or TEST run environment, the programmer has to remember to add maybe
> the path name of the files directory to the common mutex name. )

With the file locking APIs (which, actually, I believe OS/400 also
supports) you also have paths involved.

There are other Mutex APIs besides the pthread ones as well, but I don't
know if they conform to POSIX.