Global Semaphore problems

  • Thread starter Thread starter Andy
  • Start date Start date
A

Andy

Hi,

I'm trying to syncronize access to a shared resource between processes
using system semaphores.

The processes are spawned by Cruise Control.Net. I use
OpenExisting,and if that fails I catch the exception and use new
Semaphore( name );

The problem is that OpenExisting always fails, even though the other
process has created the semaphore.

The CCNET service is running as a domain user.

Any ideas?

Thanks
Andy
 
I'm trying to syncronize access to a shared resource between processes
using system semaphores.
Click to expand...

Do you want mutually exclusive access?

I think Mutex would be a better option...

Nnot sure about how you have created the first semaphore.. does the original
thread has the ownership during creation?
What is the count?
What is the upper limit?


--
Happy Hacking,
Gaurav Vaish | www.mastergaurav.com
www.edujinionline.com
http://eduzine.edujinionline.com
-----------------------------------------
 
Gaurav,

Yes, I wanted mutally exclusive access. However, no matter what I did,
the second process would throw an AbandonedMutexException when it
returned from WaitOne.

I think I did figure this out though; I now have a static variable to
hold onto the semaphore after the first nant task I wrote completes.
Then the second one attempts to access that static variable. This
seems to keep the semaphore from being GCed under a CCNET environment.

Don't know why it worked as my user and not under CCNET, but keeping a
reference to the semaphore makes it work under CCNET as well. FWIW, I
did try this same static refrence trick with the Mutex, but it always
resulted in an AbandonedMutexException.

Andy
 
Oh, to answer your questions..

Initial count was 1, max count was one. I didn't see anyway to owner
ship of a semaphor, I don't think it supports that concept.

In my aquireLock i used new Semaphore( 1, 1, LockName );

In my releaseLock I used OpenExisting..

Andy
 
Initial count was 1, max count was one. I didn't see anyway to owner
ship of a semaphor, I don't think it supports that concept.
Click to expand...

My fault... ownership is in the case of Mutex.. :D

Regarding your case... not sure but I think you earlier had a, probably,
local variable or a instance-field that got garbage-collected somewhere down
the line and hence, Semaphore being abandoned.


--
Happy Hacking,
Gaurav Vaish | www.mastergaurav.com
www.edujinionline.com
http://eduzine.edujinionline.com
-----------------------------------------
 
Regarding your case... not sure but I think you earlier had a, probably,
local variable or a instance-field that got garbage-collected somewhere down
the line and hence, Semaphore being abandoned.
Click to expand...

Semaphores don't seem to care about being abandoned. Did you mean
Mutex?

I'm not sure that was the problem either, because I held a static
reference to the mutex so that a single nant process didn't lose the
reference until the AppDomain ended..

Releasing the mutex woudl work find as it would use that static
reference, but the other process still threw the exception. Oh well,
it works now, that's all I care about.

Andy
 
Releasing the mutex woudl work find as it would use that static
reference, but the other process still threw the exception. Oh well,
it works now, that's all I care about.
Click to expand...

Hmm... all's well that ends well.
Probably, I'll put this "interesting" study in my blog.

Let me also try to reproduce it here... :)


--
Happy Hacking,
Gaurav Vaish | www.mastergaurav.com
www.edujinionline.com
http://eduzine.edujinionline.com
-----------------------------------------
 
Well to accurately repo this, you'll have to create a pair of Nant
tasks.. one to get the Mutex and one to release it. The idea is that
in your build file you get the lock, do some stuff, then release the
lock.

The AbandonedMutexException would show up just opening a couple of
console windows and running the same test build (which had a sleep
between getting and releasing the lock).

HTH
Andy
 
Well to accurately repo this, you'll have to create a pair of Nant
tasks.. one to get the Mutex and one to release it. The idea is that
in your build file you get the lock, do some stuff, then release the
lock. Oh, the tasks also took a lockName which was used to globally
name the mutex.

The AbandonedMutexException would show up just opening a couple of
console windows and running the same test build (which had a sleep
between getting and releasing the lock).

HTH
Andy
 
Back
Top