If I understand correctly a «with atomic» is a STM transaction, I call it
ST for short in what follows and DBT for database transaction.
So far my understanding is: two concurrent transaction like:
with atomic:
v1 = self.dict['k1']
Always succeed aka. don't neet to rollback to commit again.
The following concurrent always succeed:
with atomic:
v1 = self.dict['k1']
with atomic:
v2 = self.dict['k2']
The following concurrent always succeed:
with atomic:
self.dict['k1'] = v1
with atomic:
self.dict['k2'] = v2
The following read and another write succeed:
with atomic:
v1 =self.dict['k]
with atomic:
self.dict['k'] = v2
And that this succeed only if there isn't a parallele write on the same key:
with atomic:
self.dict['k1'] = self.dict['k1'] + 1
I'm asking because I can think of another rather different approach,
> which would be more in-line with pypy-stm's ultimate goals. Your
> module is defining a database-like structure that works like an
> in-memory key-value store -- some kind of generalized dictionary. So
> the "hard" question, from the point of view of STM, is what occurs if
> user code runs transactions that each want to access or modify
> different keys.
>
> In other words, what if there are multiple threads that all run in a
> "with atomic" statement, and that try to change different keys of the
> same database? What we would like to occur is that the multiple
> threads all succeed; what is likely to occur instead is that most of
> them will conflict and rollback.
Well, this is a bit confusing I'm not sure I understand how it works.
The API of «suggest» works like this:
- SUGGESTADD(key, value): possibly create «key» and add «value» as valid
word, this is *at least* two ST one for adding the key, and several for
adding the trigrams say you have the word ALAMBRA it will do one ST for
each trigrams ALA, LAM, AMB etc... plus the initial key creation which is
another ST
- SEARCH(key, value): suggest a list of words for «value» this is only one
read hence one «with atomic» hence one ST to read
Regarding ST vs DBT: In the case of Memo DBT are STs (or are though to be).
But it's probably possible to
> redesign the internals of the database to avoid this, at least most of
> the time.
>
I'm not sure how.
> How to do this exactly is not clear, and depends on the context.
> Also, we could argue that it would be great if regular python
> dictionaries had this property too: writing or accessing different
> keys should not cause a transaction to rollback (which comes with a
> few hard questions like what to do with __eq__/__hash__).
>
I'm not sure either how this can be embedded in a dict class because
sometimes one needs to use
«with atomic» as a DBT for instance if you move a value between two keys.
_______________________________________________
pypy-dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/pypy-dev
