On 24/05/2014 12:29, Piotrek wrote:
> Wyjaśnijcie mi taką jedną rzecz. Niby mam ogólne,
> teoretyczne pojęcie o wielowątkowości - wiem z czym
> to się je, jakie problemy wiążą się z programowaniem
> wielowątkowym, ale zawsze zastanawiała mnie taka jedna
> fundamentalna kwestia: dlaczego programiści w ogóle muszą
> być świadomi tego, że programują wielowątkowo, tzn. dlaczego
> samodzielnie muszą używać muteksów i innych mechanizmów
> synchronizacji wątków? Może bredzę, ale nie dałoby się tego
> jakoś rozwiązać na poziomie samego języka? Dlaczego każda
> instrukcja programu nie jest domyślnie atomowa, tzn. kompilator
> przy generowaniu kodu sam nie emuluje atomowości
> wstawiając gdzie trzeba różne locki/unlocki tak, żeby
> w ogóle nie trzeba było o tym myśleć? Chodzi o to, że
> byłoby to niewydajne?

W Erlangu, Haskellu czy Go możesz spokojnie pisać programy wykonujące
się na wielu wątkach bez żadnego grzebania w lockach.

Jeśli chodzi konkretnie o programowanie imperatywne z dzieleniem stanu,
to również istnieją biblioteki pozwalające na ominięcie problemu jawnego
używania locków, ale oczywiście samo użycie nie gwarantuje braku data
races w programie. To, co proponujesz rzeczywiście byłoby niewydajne -
nawet tam, gdzie architektura gwarantuje atomowość pewnych operacji (np.
zapisu lub odczytu słowa maszynowego) optymalizacje procesora powodują
że poszczególne atomowe operacje mogą być widoczne w różnej kolejności z
różnych wątków. O większych operacjach, gdzie kompilator musiałby
zakładać locka za każdym razem, kiedy instrukcja języka przekłada się na
więcej niż jedną instrukcję procesora już lepiej nie mówić. Przede
wszystkim jednak nie rozwiązuje to problemu: kompilator nadal nie wie,
co jest atomową instrukcją z punktu widzenia semantyki twojego programu.
Wyobraź sobie np. że masz taką strukturę jak lista dwukierunkowa.
Operacje jak wstawienie czy usunięcie elementu wymagają kilku operacji
odczytania i zapisania wskaźników. Nawet jeśli każda z tym operacji na
wskaźnikach jest atomowa, a nawet jeśli kompilator zadbał żeby np.
skopiowanie wartości wskaźnika było atomową operacją, to nadal (jeśli
nie zaznaczysz tego jakoś w programie) kompilator nie ma podstaw żeby
uważać, że tych kilka kopiowań wskaźników jest również operacją atomową
- to ty wiesz, że implementujesz listę dwukierunkową, kompilator tego
nie wie. I oczywiście jeśli same kopiowania są atomowe, ale całe
wstawienie/usunięcie elementu nie jest, to masz data race: co by się
działo jakby w połowie wstawiania elementu do listy przez jeden wątek
drugi postanowił wykonać inną operację - np. usunąć poprzedzający
element? Oczywiście tak w ogóle da się zdefiniować listę z zaznaczeniem
co jest atomową operacją bez jawnego używania locków - poczytaj sobie
np. o monitorach.