Re: Named Semaphores
Re: Named Semaphores
- Subject: Re: Named Semaphores
- From: Mark Stultz <email@hidden>
- Date: Fri, 03 Jun 2005 12:50:42 -0500
Ok, I am very very tired :) I don't like to reply to myself, but for
archiving purposes, I'd like to point out my finding. I thought semaphore
IDs themselves are global, but they are not. So two apps may have a
semaphore named "/MySemaphore", and it is only one semaphore. However, the
semaphore ids returned by sem_open may be two totally different integer
values. Good to know it wasn't something wrong with my code :)
Mark Stultz
United Developers
email@hidden
On 6/3/05 11:59 AM, "Mark Stultz" <email@hidden> wrote:
> I have tried them with and without the slashes with no prevail. Apple's
> SharedMemory.app example code doesn't use a slash either. I am totally
> confused as to what may be the case. I especially do not know why semaphore
> IDs would overlap. It doesn't seem as if they're global.
>
>
> On 6/3/05 11:54 AM, "AgentM" <email@hidden> wrote:
>
>> Please read:
>> http://www.opengroup.org/onlinepubs/007908799/xsh/sem_open.html
>>
>> Specifically, names that do not begin with a slash results in
>> something implementation-dependent. Try a path or just "/test" or "/
>> tmp/test".
>>
>> On Jun 3, 2005, at 11:42 AM, Mark Stultz wrote:
>>
>>> (also posted on unix-porting...)
>>> If this is posted to the wrong list, please let me know of a more
>>> appropriate listing. I am porting a unix program that utilizes named
>>> pthreads to lock certain things in one program, and in another "child"
>>> program, it sees if it locks for certain tests.
>>>
>>> I'd like to preface this by saying we are using the 10.2.8 SDK.
>>>
>>> Since we do not have named pthreads, I am using named semaphores
>>> because
>>> they are system-wide, and we are only doing locks & try locks.
>>> However,
>>> when I set up my two programs, they do not recognize each other's
>>> semaphore
>>> IDs. Some of the IDs even over lap. Here is a snippet of pseudo
>>> code I am
>>> going by...
>>>
>>> class NamedSemaphores
>>> {
>>> public:
>>> // Constructor / Destructor
>>> NamedSemaphores( const char *name_ = 0 )
>>> {
>>> // See if it exists first
>>> _semaphoreID = ::sem_open( name_, 0 );
>>>
>>> printf("semid = %i\n", (int)_semaphoreID );
>>>
>>> if ( ( int )_semaphoreID == SEM_FAILED )
>>> {
>>> // Otherwise, create it
>>> _semaphoreID = ::sem_open( name_, O_CREAT, 0777, 0 );
>>> }
>>>
>>> if ( ( int )_semaphoreID == SEM_FAILED )
>>> {
>>> printf( "SEM_FAILED\n" );
>>> }
>>> }
>>>
>>> ...continues with more class functions...
>>>
>>> private:
>>> sem_t *_semaphoreID;
>>> }
>>>
>>> I had to edit that really quick, so the syntax may contain a typo or
>>> something. At any rate, both programs are pretty much identical,
>>> and they
>>> are both calling a:
>>>
>>> NamedSemaphores *mySemaphore;
>>> MySemaphore = new NamedSemaphores( "TEST" );
>>>
>>> Obviously I am not using that string, but more like 5 different
>>> strings.
>>> Program A might return semaphoreID's of: 4, 5, 6, 7, and 8.
>>> Program B
>>> might return semaphoreID's of 7, 8, 9, 10, and 11. They do not
>>> recognize
>>> identical strings, and they also overlap certain semaphoreIDs.
>>>
>>> Any clues as to what might be happening?
>>>
>>> Mark Stultz
>>> United Developers
>>> email@hidden
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Unix-porting mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>> 40udgames.com
>>>
>>> This email sent to email@hidden
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Darwin-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>> 40themactionfaction.com
>>>
>>> This email sent to email@hidden
>>>
>>
>> |-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
>> AgentM
>> email@hidden
>> |-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
>>
>
>
> Mark Stultz
> United Developers
> email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Darwin-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden