> Carl Banks (CB) wrote:
>CB> On Apr 6, 2:23 pm, "Diez B. Roggisch" wrote:
>>> > This is a classical synchronization problem with a classical solution:
>>> > You treat the readers as a group, and the writers individually. So you
>>> > have a write lock that each writer has to acquire and rel
> "Diez B. Roggisch" (DBR) wrote:
>>> This is a classical synchronization problem with a classical solution:
>>> You treat the readers as a group, and the writers individually. So you
>>> have a write lock that each writer has to acquire and release, but it is
>>> acquired only by the first r
On Apr 6, 2:23 pm, "Diez B. Roggisch" wrote:
> > This is a classical synchronization problem with a classical solution:
> > You treat the readers as a group, and the writers individually. So you
> > have a write lock that each writer has to acquire and release, but it is
> > acquired only by the f
On Apr 6, 3:30 am, "Emanuele D'Arrigo" wrote:
> Python's approach with the GIL is both reasonable and disappointing.
> Reasonable because I understand how it can make things easier for its
> internals. Disappointing because it means that standard python cannot
> take advantage of the parallelism t
Python's approach with the GIL is both reasonable and disappointing.
Reasonable because I understand how it can make things easier for its
internals. Disappointing because it means that standard python cannot
take advantage of the parallelism that can more and more often be
afforded by today's com
This is a classical synchronization problem with a classical solution:
You treat the readers as a group, and the writers individually. So you
have a write lock that each writer has to acquire and release, but it is
acquired only by the first reader and released by the last one.
Therefore you need
On Apr 6, 12:44 pm, Piet van Oostrum wrote:
> 3. See also http://code.activestate.com/recipes/465156/
Thank you for the useful suggestions Piet. In particular I just had a
look at the SharedLock class provided through the link above and it
seems to fit the bill quite nicely. I'll give it a go!
T
> "Emanuele D'Arrigo" (ED) wrote:
>ED> Hi everybody,
>ED> I'm having a threading-related design issue and I suspect it has a
>ED> name that I just don't know. Here's a description.
>ED> Let's assume a resource (i.e. a dictionary) that needs to be accessed
>ED> by multiple threads. A simple
On Apr 6, 7:49 am, "Diez B. Roggisch" wrote:
> The CPython-specific answer is that the GIL takes care of that for you
> right now anyway. So unless you plan for a distant future where some
> kind of swallows fly around that don't have a GIL, you are safe to
> simply read and write in threads witho
Emanuele D'Arrigo schrieb:
Hi everybody,
I'm having a threading-related design issue and I suspect it has a
name that I just don't know. Here's a description.
Let's assume a resource (i.e. a dictionary) that needs to be accessed
by multiple threads. A simple lock will do the job but in some
ci
10 matches
Mail list logo
