Parallel(?) programming with python

Andreas Croci andrea.croci at gmx.de
Mon Aug 8 13:39:27 EDT 2022


Thank you for your reply.

On 08.08.22 14:55, Julio Di Egidio wrote:

> Concurrent programming is quite difficult, plus you better think
> in terms of queues than shared data... 

Do you mean queues in the sense of deque (the data structure)? I ask 
because I can see the advantage there when I try to pop data from the 
front of it, but I don't see the sense of the following statement ("than 
shared data"). I mean, I called my structure a list, but it may well be 
a queue instead. That wouldn't prevent it from being shared in the idea 
I described: one function would still append data to it while the other 
is reading what is there up to a certain point and calculate the FFT of it.

  But, an easier and often
> better option for concurrent data access is use a (relational)
> database, then the appropriate transaction isolation levels
> when reading and/or writing.
> 

That would obviusly save some coding (but would introduce the need to 
code the interaction with the database), but I'm not sure it would speed 
up the thing. Would the RDBMS allow to read a table while something else 
is writing to it? I doubt it and I'm not sure it doesn't flush the cache 
before letting you read, which would include a normally slow disk access.

Andreas

> Julio



More information about the Python-list mailing list