Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.lang.python > #5876
| From | Stefan Schwarzer <sschwarzer@sschwarzer.net> |
|---|---|
| Newsgroups | de.comp.lang.python |
| Subject | [Python-de] Re: Code Style Review |
| Date | 2022-11-29 18:51 +0100 |
| Message-ID | <3d4a86fc-9794-30bb-4f28-6154caf24cfa@sschwarzer.net> (permalink) |
| References | <tm2jhn$1k5h8$1@news1.tnib.de> <480b80d21e58d280c437b4854bfc7cf1@posteo.de> <d60e87cd-51b9-084e-3fb6-d15b7588004d@chrisarndt.de> <tm37ut$1lfhm$1@news1.tnib.de> |
On 2022-11-28 22:07, Marc Haber wrote: > Kann ich die Locks innerhalb der entsprechenden Funktion definieren > oder bekomme ich dann in jedem Thread ein eigenes Lock, was der > Intention entgegen spricht? > > Ist: > > foolock = threading.Lock() > def foo: > with foolock: > (tue Dinge mit foo, potenziell multithreaded) > > dasselbe wie > > def foo: > foolock = threading.Lock() > with foolock: > (tue Dinge mit foo, potenziell multithreaded) > > ? Die Ansätze sind _nicht_ gleichwertig. Wie du richtig erkannt/vermutet hast, definierst du im zweiten Ansatz bei Ausführung von `foo` "on the fly" ein Lock-Objekt. Dieses hat mit anderen Lock-Objekten, die in anderen Threads in `foo` erzeugt werden, nichts zu tun. Das Lock ist damit wirkungslos (vielleicht mal abgesehen von dem Sonderfall, dass du das Lock in anderen Aufrufen im `with`-Block weiterreichst, aber das ist eine ganz andere Semantik, die du hier vermutlich nicht im Sinn hast :-) ). > Ist die in > https://www.bogotobogo.com/python/Multithread/python_multithreading_Using_Locks_with_statement_Context_Manager.php > und > https://www.pythontutorial.net/python-concurrency/python-threading-lock/ > verwendete Schreibweise, wo das Lock als Parameter mit in die Funktion > hineingereicht wird, wirklich "schönes" Python? Allgemein würde ich nicht `acquire` und `release` explizit verwenden beziehungsweise die meisten der Situationen, wo man `acquire` und `release` verwendet, können mit einem `with some_lock:` übersichtlicher geschrieben werden. > Oder schreibe ich mein ganzes Programm als eine Klasse, die genau > einmal instanziiert wird und dann in ihren statischen Variablen (so > wäre es in C++) die Tabelle, die Konfiguration, die Locks, den > Debugstatus etc hält? Sind solche Ein-Instanz-Klassen "schönes" > Python? Ich kenne so etwas unter dem Namen "Active Object"-Pattern; jedenfalls nehme ich an, dass das gemeint ist (auch wenn es sich aus meiner Sicht etwas wüst anhört, ganz verschiedene Sachen in die Instanz zu packen, falls das so gemeint ist). Ein weiterer Ansatz ist, Queues zur Synchronisation zu verwenden, was tendenziell deutlich weniger fehleranfällig ist. Ich habe vor ein paar Jahren einen Vortrag zu Nebenläufigkeit in Python gehalten, der auch Queues und Active Objects behandelt: https://sschwarzer.com/download/concurrency_pycon_de2018.pdf Viele Grüße Stefan
Back to de.comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar
Code Style Review Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-11-28 16:19 +0100
[Python-de] Re: Code Style Review c.buhtz@posteo.jp - 2022-11-28 15:37 +0000
[Python-de] Re: Code Style Review Christopher Arndt <chris@chrisarndt.de> - 2022-11-28 16:48 +0100
[Python-de] Re: Code Style Review c.buhtz@posteo.jp - 2022-11-28 19:53 +0000
Re: [Python-de] Re: Code Style Review Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-11-28 22:07 +0100
[Python-de] Re: Code Style Review Stefan Schwarzer <sschwarzer@sschwarzer.net> - 2022-11-29 18:51 +0100
[Python-de] Re: Code Style Review Marc Haber <mh+python-de@zugschlus.de> - 2022-11-29 21:44 +0100
[Python-de] Re: Code Style Review Stefan Schwarzer <sschwarzer@sschwarzer.net> - 2022-11-29 23:16 +0100
Re: [Python-de] Re: Code Style Review Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-11-28 21:52 +0100
[Python-de] Re: Code Style Review c.buhtz@posteo.jp - 2022-11-28 22:38 +0000
Re: [Python-de] Re: Code Style Review Enrik Berkhan <Enrik.Berkhan@inka.de> - 2022-11-29 06:03 +0000
Re: [Python-de] Re: Code Style Review Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-11-29 15:22 +0100
[Python-de] Re: Code Style Review c.buhtz@posteo.jp - 2022-11-29 14:39 +0000
[Python-de] Re: Code Style Review Matthias Urlichs <matthias.urlichs@noris.de> - 2022-11-30 10:47 +0000
[Python-de] Re: Code Style Review Marc Haber <mh+python-de@zugschlus.de> - 2022-12-01 21:30 +0100
[Python-de] Re: Code Style Review Stefan Schwarzer <sschwarzer@sschwarzer.net> - 2022-12-02 00:07 +0100
Re: [Python-de] Re: Code Style Review "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-12-03 14:32 +0100
[Python-de] Re: Code Style Review Matthias Urlichs <matthias.urlichs@noris.de> - 2022-12-02 09:29 +0000
[Python-de] Re: Code Style Review Marc Haber <mh+python-de@zugschlus.de> - 2022-12-02 18:02 +0100
[Python-de] Re: Code Style Review Stefan Schwarzer <sschwarzer@sschwarzer.net> - 2022-11-29 18:33 +0100
[Python-de] Re: Code Style Review Stefan Schwarzer <sschwarzer@sschwarzer.net> - 2022-11-29 18:18 +0100
[Python-de] Re: Code Style Review Hans-Peter Jansen <hpj@urpla.net> - 2022-11-30 15:52 +0100
[Python-de] Re: Code Style Review Marc Haber <mh+python-de@zugschlus.de> - 2022-12-01 21:16 +0100
[Python-de] Re: Code Style Review Stefan Schwarzer <sschwarzer@sschwarzer.net> - 2022-12-01 23:58 +0100
[Python-de] Re: Code Style Review Marc Haber <mh+python-de@zugschlus.de> - 2022-12-02 18:10 +0100
Re: [Python-de] Re: Code Style Review "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-12-03 14:36 +0100
csiph-web