In article <[EMAIL PROTECTED]>, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> I guess I would be inclined to propose separate flags for indicating > the operation that the caller will attempt (read or write) and the > level of locking (lock the buffer's address or also prevent anyone > else from writing). Then a "classic read lock" would request read > access while locking out writers (bsddb would use this); a "classic > write lock" would request write access while locking out writers (your > scratch area example would use this); others who don't really care if > the data changes underneath them as long as it doesn't move (e.g. > traditional I/O) could request read access without locking. I'm not > sure if there's a use case to be made for write access without > locking, but I wouldn't rule it out -- possibly when two threads share > a memory area they might have their own protocol for locking it and > might just both want to be able to write to (parts of) it. > > What do you think? Another way to look at this would be to consider > these 4 cases: > > basic read access (I can read, others can read or write) > locked read access (I can read, others can only read) > basic write access (I can read and write, others can read or write) > exclusive write access (I can read and write, no others can read or write) Sounds much like the modes offered by an old operating system that had a very nice lock manager. The modes: - concurrent read (others can read or write) - protected read (others can read but not write) - concurrent write (others can read or concurrent write) - protected write (others can concurrent read) - exclusive (no other locks allowed) (as well as null to release the resource) Some of these modes were intended for resources that are locked at multiple levels (which I don't think applies to array buffers). For example one might get a concurrent lock for a group of resources, then a protected lock for one resource. But as you say, there are some situations where concurrent write might be useful. -- Russell _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
