Threading

[Tim Peters]

[Ciobanu Vladimir]
> ...
>    If I'm calling only functions such as __getitem__ ( and maybe
> querry which mainly calls .has_key( key)), is it safe not to add locks
> to these functions ?
>    I would ask you not to answer if you're not sure about the answer.
> This is quite important, since it would be a major draw-back if two
> users couldn't read  at the same time. It doesn't make sence, either.

In this case, being sure about the answer is much easier than being sure
about the question <wink>.  If you run *any* sequence of dict operations
without benefit of locks (get, set, update, clear, whatever), the outcome
will be "sequentially consistent", meaning the outcome will be the same as
if you had run the dict operations one at a time with benefit of exclusion,
for *some* intervleaving of dict operations across threads:  each dict
operation is atomic (e.g., once a dict.update() starts, it completes before
another thread is allowed to run).   In particular, if there are no
mutations going on, any number of threads can read simultaneously without
locks without surprises.

However:

> I will add a property to DataBase, namely __readonly. If one user
> opens it as __readonly, calling function members that change the data
> in the DataBase ( such as __setitem__) then an exception is raised. I
> will allow one, and only one user to modify the database at a time.
> Plus if one is modifyiny, none can read.

You can't achieve the last point unless you use *some* synch scheme for
reads too, else a mutator would have no way to know that a read may be in
progress.  A "multiple-reader single-writer" (MRSW) lock is par for that
course.