At 11:51 AM +1200 6/1/06, Sam Vilain wrote:
I think the answer lies in the "checkpointing" references in that
document. I don't know whether that's akin to a SQL savepoint (ie, a
point mid-transaction that can be rolled back to, without committing the
entire transaction) or more like a continuat
--- John Drago <[EMAIL PROTECTED]> wrote:
> James Mastros wrote:
> > I don't like the name synchronized -- it implies that multiple
> > things are happening at the same time, as in synchronized swiming,
> > which is exactly the opposite of what should be implied.
> > "Serialized" would be a nice n
Daniel Hulme wrote:
>>How does an atomic block differ from one in which all variables are
>>implicitly hypotheticalized?
>>
>>
>I assume that the atomicness being controlled by some kind of lock on
>entry, it also applies to I/O and other side-effecty things that you
>can't undo.
>
The lock o
Jonathan Lang wrote:
>How does an atomic block differ from one in which all variables are
>implicitly hypotheticalized? I'm thinking that a "retry" exit
>statement may be redundant; instead, why not just go with the existing
>mechanisms for successful vs. failed block termination, with the minor
Thanks to all who have read or replied -
I'm reading the Concurrency POD right now - more questions when I'm done.
John Drago | VP Software Engineering
[EMAIL PROTECTED]
www.precissystems.com
> -Original Message-
> From: Benjamin Smith [mailto:[E
James Mastros wrote:
> I don't like the name synchronized -- it implies that multiple things are
> happening at the same time, as in synchronized swiming, which is exactly the
> opposite of what should be implied. "Serialized" would be a nice name,
> except it implies serializing to a serial form
> How does an atomic block differ from one in which all variables are
> implicitly hypotheticalized?
I assume that the atomicness being controlled by some kind of lock on
entry, it also applies to I/O and other side-effecty things that you
can't undo.
--
Hats are no worse for being made by ancien
How does an atomic block differ from one in which all variables are
implicitly hypotheticalized? I'm thinking that a "retry" exit
statement may be redundant; instead, why not just go with the existing
mechanisms for successful vs. failed block termination, with the minor
modification that when an
On Tue, May 30, 2006 at 03:41:06PM -0600, John Drago wrote:
> class Foo is synchronized {
> ...
> }
>
> our method Bar is synchronized {
> ...
> }
>
> class Baz {
> has $.Bux is synchronized;
> }
To everyone participating in this thread:
There has already been a draft spec for concurrency
How about one of these?
==
class Baz {
has $.a is restricted;
has $.b is controlled;
has $.c is unique;
has $.d is shared;
has $.e is queued;
has $.f is token;
...
}
--- John Drago <[EMAIL PROTECTED]> wrote:
> I asked this via the Google Groups interfa
We could always go with the Windows API "Critical Section" name. Locked is
probably as good a descriptor, and avoids anything associated with Windows.
Sage
James Mastros skribis 2006-05-31 12:03 (+0100):
> I don't like the name synchronized -- it implies that multiple things
are
> happening at
James Mastros skribis 2006-05-31 12:03 (+0100):
> I don't like the name synchronized -- it implies that multiple things are
> happening at the same time, as in synchronized swiming, which is exactly the
> opposite of what should be implied. "Serialized" would be a nice name,
> except it implies se
On Tue, May 30, 2006 at 03:41:06PM -0600, John Drago wrote:
> I asked this via the Google Groups interface a few weeks ago, but I'm not
> sure if it made it here.
> I am asking again in case the question never made it onto the list.
>
> Has the syntax for synchronized/threaded @things been worked
I asked this via the Google Groups interface a few weeks ago, but I'm not sure
if it made it here.
I am asking again in case the question never made it onto the list.
Has the syntax for synchronized/threaded @things been worked out?
For example:
class Foo is synchronized {
...
}
our method Ba
14 matches
Mail list logo
