[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pika-dev] Guile FFI: resizable vector problem
From: |
Denys Duchier |
Subject: |
Re: [Pika-dev] Guile FFI: resizable vector problem |
Date: |
Wed, 04 Feb 2004 00:13:36 +0100 |
User-agent: |
Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) |
Tom Lord <address@hidden> writes:
> scm_vector_{set,ref} are, indeed, semantically required to be atomic
> operations. Should the representations provide threads, they must,
> indeed, be implemented with some form of locking.
There was perhaps a not so obvious point in my remarks about coherence
with an interleaving semantics: while locking is the simplest way to
enforce correctness, it is not always necessary if you know how to
squint in just the right way :-)
First a disclaimer: I have not thought about the issue very long, and
while I have quite a bit of experience with designing concurrent
abstractions, the semantics of concurrency is by no means my area of
expertise.
My suspicion is that it is actually ok to not lock. A proof is
needed, but it might go along those lines:
Terminology:
vector has a pointer to the vector array
vector array contains vector array elements
vector array element
- the interesting time points are those where the vector array is
replaced with a new one
- an important assumption in my suggestion is that the vector array
is subject to normal GC and not explicitly recycled when e.g. the
vector is resized
if V is a vector and it is successively assigned vector arrays A1,
..., An, then these points of assignment are the interesting
timepoints.
The operations on a vector V are:
vector-ref(V,I)
1. A = V.array
2. return A[I]
vector-set!(V,I,X)
1. A = V.array
2. A[I] = X
The issue is what happens for operations when the transition from Ak
to Ak+1 happens between steps 1 and 2? Is there still a way to pretend
that these individual operations are actually executed atomically?
The ordering for the interleaving semantics of concurrent operations
on vector V is determined as follows. First, each operation is
initiated between some Ak and Ak+1 (i.e. the first step executes when
Ak is the array and before it is replaced by Ak+1). Let Tk be the
(global) timepoint when V is assigned Ak. The second step takes place
at (global time) T. We can order the operations using the
lexicographic order on the pair (Tk,T) for each actual operation: the
point is that the operations _could_ have been executed in this
particular order and would have resulted in the currently observable
state - and (from the language level) we have no way to tell that this
was not what actually took place. Thus the observable semantics is
consistent with _some_ interleaving.
This is of course very hand-wavy and since it lacks a formal proof, it
could easily be wrong... but you get the idea.
Cheers,
--
Dr. Denys Duchier
Équipe Calligramme
LORIA, Nancy, FRANCE
- Re: [Pika-dev] Guile FFI: resizable vector problem, Tom Lord, 2004/02/01
- Re: [Pika-dev] Guile FFI: resizable vector problem, Denys Duchier, 2004/02/03
- Re: [Pika-dev] Guile FFI: resizable vector problem, Tom Lord, 2004/02/03
- Re: [Pika-dev] Guile FFI: resizable vector problem,
Denys Duchier <=
- Re: [Pika-dev] Guile FFI: resizable vector problem, Tom Lord, 2004/02/03
- Re: [Pika-dev] Guile FFI: resizable vector problem, duchier, 2004/02/04
- Re: [Pika-dev] Guile FFI: resizable vector problem, Matthew Dempsky, 2004/02/04
- Re: [Pika-dev] Guile FFI: resizable vector problem, duchier, 2004/02/04
- Re: [Pika-dev] Guile FFI: resizable vector problem, Tom Lord, 2004/02/04
- Re: [Pika-dev] Guile FFI: resizable vector problem, Denys Duchier, 2004/02/04
- Re: [Pika-dev] Guile FFI: resizable vector problem, Tom Lord, 2004/02/04
Re: [Pika-dev] Guile FFI: resizable vector problem, Andreas Rottmann, 2004/02/20