I'm revisiting some code I ported from squeak a while back and am
wondering if Squeaks Monitor class is analogous to VW's Semaphore or something else? I'm currently using the Semaphore class as an alternative but wanted to double-check.. Below is part of the Squeak comment block for the Monitor class : ===================== A monitor provides process synchronization that is more high level than the one provided by a Semaphore. Similar to the classical definition of a Monitor it has the following properties: 1) At any time, only one process can execute code inside a critical section of a monitor. 2) A monitor is reentrant, which means that the active process in a monitor never gets blocked when it enters a (nested) critical section of the same monitor. 3) Inside a critical section, a process can wait for an event that may be coupled to a certain condition. If the condition is not fulfilled, the process leaves the monitor temporarily (in order to let other processes enter) and waits until another process signals the event. Then, the original process checks the condition again (this is often necessary because the state of the monitor could have changed in the meantime) and continues if it is fulfilled. 4) The monitor is fair, which means that the process that is waiting on a signaled condition the longest gets activated first. 5) The monitor allows you to define timeouts after which a process gets activated automatically. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
1. and 2. sounds like a RecursionLock. However, I think 3. is a
feature that isn't supported by a RecursionLock. HTH, Wouter On Thu, Jan 29, 2009 at 7:31 AM, Richard E. Flower <[hidden email]> wrote: > I'm revisiting some code I ported from squeak a while back and am > wondering if Squeaks Monitor class is analogous to VW's Semaphore or > something else? > I'm currently using the Semaphore class as an alternative but wanted > to double-check.. Below is part of the Squeak comment block for the > Monitor class : > > ===================== > A monitor provides process synchronization that is more high level > than the one provided by a Semaphore. Similar to the classical > definition of a Monitor it has the following properties: > > 1) At any time, only one process can execute code inside a critical > section of a monitor. > 2) A monitor is reentrant, which means that the active process in a > monitor never gets blocked when it enters a (nested) critical section > of the same monitor. > 3) Inside a critical section, a process can wait for an event that may > be coupled to a certain condition. If the condition is not fulfilled, > the process leaves the monitor temporarily (in order to let other > processes enter) and waits until another process signals the event. > Then, the original process checks the condition again (this is often > necessary because the state of the monitor could have changed in the > meantime) and continues if it is fulfilled. > 4) The monitor is fair, which means that the process that is waiting > on a signaled condition the longest gets activated first. > 5) The monitor allows you to define timeouts after which a process > gets activated automatically. > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > -- Wouter Gazendam AG5 B.V. Timorplein 37 1094 CC Amsterdam www.ag5.nl Tel: 020-4630942 Fax: 020-4630946 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Rick Flower
Richard E. Flower wrote:
> I'm revisiting some code I ported from squeak a while back and am > wondering if Squeaks Monitor class is analogous to VW's Semaphore or > something else? > I'm currently using the Semaphore class as an alternative but wanted > to double-check.. Below is part of the Squeak comment block for the > Monitor class : In Smalltalk (at least in most implementations) the semaphore is the fundamental synchronization primitive. It's possible to build monitors on top of semaphores. It's also possible to build semaphores on top of monitors. I haven't looked at the Squeak monitor implementation to see how they do it. If they built their monitors on top of semaphores, then you could probably use the Squeak monitor implementation in VW. If they added monitors at a lower level, then you'd have more work to do. Regards, -Martin _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Thanks all for the replies..
When I wrote this I was not sure the code I was reviewing was working properly after being ported from the Squeak environment -- it turned out to be a time calculation issue with my Glorp connection pool (care of Ramon Leon on the Seaside mailing list).. Anyway I've gotten past this hurdle and after moving to Chronos style times my connection expirations are working as they ought to.. If anyone is interested I'll probably publish Ramon's MGConnectionPool code in the public store for other to use since it has a few differences from the Squeak version that Ramon came up with.. -- Rick On Thu, January 29, 2009 11:13 am, Martin McClure wrote: > Richard E. Flower wrote: >> I'm revisiting some code I ported from squeak a while back and am >> wondering if Squeaks Monitor class is analogous to VW's Semaphore or >> something else? >> I'm currently using the Semaphore class as an alternative but wanted >> to double-check.. Below is part of the Squeak comment block for the >> Monitor class : > > In Smalltalk (at least in most implementations) the semaphore is the > fundamental synchronization primitive. It's possible to build monitors > on top of semaphores. It's also possible to build semaphores on top of > monitors. > > I haven't looked at the Squeak monitor implementation to see how they do > it. If they built their monitors on top of semaphores, then you could > probably use the Squeak monitor implementation in VW. If they added > monitors at a lower level, then you'd have more work to do. > > Regards, > > -Martin > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Wouter Gazendam
As Wouter said, #1 and #2 are handled by RecursionLock. I am aware of no equivalent for #3, but it's somewhat unclear to me exactly how this works. You could do that by basically implementing the critical section in-and-out behavior in a Monitor that used a private RecursionLock. I'm just not sure how the event stuff would work, etc. I think #4 is only partially possible because of how the scheduler works. When a semaphore is signaled, I don't know if it is the longest waiting process or the one such at the highest priority that runs. #5 could be handled similar to #3, forcing the owning process behavior to be aborted with a timeout signal.
Cheers! Tom Hawker -------------------------- Senior Framework Developer -------------------------- Home +1 (408) 274-4128 Office +1 (408) 576-6591 Mobile +1 (408) 835-3643 -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Wouter Gazendam Sent: Thursday, January 29, 2009 12:13 AM To: Richard E. Flower Cc: VW NC Subject: Re: [vwnc] Squeak's 'Monitor' class maps to VW's Semaphore or ?? 1. and 2. sounds like a RecursionLock. However, I think 3. is a feature that isn't supported by a RecursionLock. HTH, Wouter On Thu, Jan 29, 2009 at 7:31 AM, Richard E. Flower <[hidden email]> wrote: > I'm revisiting some code I ported from squeak a while back and am > wondering if Squeaks Monitor class is analogous to VW's Semaphore or > something else? > I'm currently using the Semaphore class as an alternative but wanted > to double-check.. Below is part of the Squeak comment block for the > Monitor class : > > ===================== > A monitor provides process synchronization that is more high level > than the one provided by a Semaphore. Similar to the classical > definition of a Monitor it has the following properties: > > 1) At any time, only one process can execute code inside a critical > section of a monitor. > 2) A monitor is reentrant, which means that the active process in a > monitor never gets blocked when it enters a (nested) critical section > of the same monitor. > 3) Inside a critical section, a process can wait for an event that may > be coupled to a certain condition. If the condition is not fulfilled, > the process leaves the monitor temporarily (in order to let other > processes enter) and waits until another process signals the event. > Then, the original process checks the condition again (this is often > necessary because the state of the monitor could have changed in the > meantime) and continues if it is fulfilled. > 4) The monitor is fair, which means that the process that is waiting > on a signaled condition the longest gets activated first. > 5) The monitor allows you to define timeouts after which a process > gets activated automatically. > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > -- Wouter Gazendam AG5 B.V. Timorplein 37 1094 CC Amsterdam www.ag5.nl Tel: 020-4630942 Fax: 020-4630946 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc IMPORTANT NOTICE Email from OOCL is confidential and may be legally privileged. If it is not intended for you, please delete it immediately unread. The internet cannot guarantee that this communication is free of viruses, interception or interference and anyone who communicates with us by email is taken to accept the risks in doing so. Without limitation, OOCL and its affiliates accept no liability whatsoever and howsoever arising in connection with the use of this email. Under no circumstances shall this email constitute a binding agreement to carry or for provision of carriage services by OOCL, which is subject to the availability of carrier's equipment and vessels and the terms and conditions of OOCL's standard bill of lading which is also available at http://www.oocl.com. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |