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

["Steve Richter" <srichter@xxxxxxxxxxxxx>]

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Scott Klement
Sent: Monday, October 06, 2003 6:31 PM
To: Midrange Systems Technical Discussion
Subject: Re: posix mutex vs win32 mutex. was why linux?


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

I've used ALCOBJ on a dtaara as a way to tell that a job is already active
and should not be submitted again.  Works better than setting a flag in a
dtaara or control file because sometimes the flag gets stuck.  The ALCOBJ
lock goes away automatically when the job ends.

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

In WIN32 shared memory has to be first created/opened ( with a long unique
name assigned to the memory block ), then mapped to the memory of the
thread.

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

Thats interesting.  In WIN32 there is no such API. Files can of course be
opened exclusively or shared.  But they cant be locked and a thread has no
way of going into a wait state while waiting for the file to not be in use.

Good enough. Hopefully I will receive my book soon.

http://www.amazon.com/exec/obidos/tg/detail/-/0201563177/002-0265981-9979277
?v=glance

-Steve