I have a resource that I only want to be used by one process at a time. I've created a ResourceManager class to encapsulate this policy.
ResourceManager>>doWithResource: aOneArgumentBlock mutexSemaphore critical: [aOneArgumentBlock value: myResource]
Only one process can be using the resource "myResource" at a time. Do I have that right?
The problem I have is that if I leave my program running for a few days, I invariably find it hung, waiting to execute a critical section. I don't see any debugger window popping up, so no error was encoutered. Does that mean that one of my blocks that I'm passing in is never finishing?
Thank you
Derek Brans Nerd on a Wire Web design that's anything but square http://www.nerdonawire.com mailto: brans@nerdonawire.com phone: 604.874.6463 toll-free: 1-877-NERD-ON-A-WIRE
On Friday 01 August 2003 05:07 pm, Derek Brans wrote:
I have a resource that I only want to be used by one process at a time. I've created a ResourceManager class to encapsulate this policy.
ResourceManager>>doWithResource: aOneArgumentBlock mutexSemaphore critical: [aOneArgumentBlock value: myResource]
Only one process can be using the resource "myResource" at a time. Do I have that right?
The problem I have is that if I leave my program running for a few days, I invariably find it hung, waiting to execute a critical section. I don't see any debugger window popping up, so no error was encoutered. Does that mean that one of my blocks that I'm passing in is never finishing?
Yes, but not necessarily because it's taking too long to get its work done.
If you happen to call this from a Process that's already gotten the semaphore, you'll block that process. Which is probably not what you want.
You should look at Nathanael's Monitor class; it lets you have timeouts and not worry about the same Process obtaining the lock multiple times.
I> If you happen to call this from a Process that's already gotten the
semaphore, you'll block that process. Which is probably not what you want.
I've been careful to avoid that.
You should look at Nathanael's Monitor class; it lets you have timeouts and not worry about the same Process obtaining the lock multiple times.
Fabulous. Don't see "Monitor" in the image or on SM. Is that the same as WAProcessMonitor?
Thanks.
On Friday 01 August 2003 07:31 pm, Derek Brans wrote:
I> If you happen to call this from a Process that's already gotten the
semaphore, you'll block that process. Which is probably not what you want.
I've been careful to avoid that.
You should look at Nathanael's Monitor class; it lets you have timeouts and not worry about the same Process obtaining the lock multiple times.
Fabulous. Don't see "Monitor" in the image or on SM. Is that the same as WAProcessMonitor?
You can get to it via Nathanael's Smalltalk page: http://www.iam.unibe.ch/~schaerli/smalltalk/
Fabulous. Don't see "Monitor" in the image or on SM. Is that the same as WAProcessMonitor?
You can get to it via Nathanael's Smalltalk page: http://www.iam.unibe.ch/~schaerli/smalltalk/
Harvester good in concurrency please consider these fixes. I know that there is a much better package with stream, but now we still have broken code that nathanael fixed nearly one year ago.
I say that because I'm plain bad in concurrent programming and I would prefer a good guy to have a look.
Stef
Hi Ned,
The timeouts in Nethaniel's code relate to waiting. I think I need to timeout the process that's holding up the critical section and get it to signal an error. Does that make sense?
On Friday 01 August 2003 07:31 pm, Derek Brans wrote:
I> If you happen to call this from a Process that's already gotten the
semaphore, you'll block that process. Which is probably not what you want.
I've been careful to avoid that.
You should look at Nathanael's Monitor class; it lets you have timeouts and not worry about the same Process obtaining the lock multiple times.
Fabulous. Don't see "Monitor" in the image or on SM. Is that the same as WAProcessMonitor?
You can get to it via Nathanael's Smalltalk page: http://www.iam.unibe.ch/~schaerli/smalltalk/
-- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE
squeak-dev@lists.squeakfoundation.org