Bash nie mogę uruchomić wielowątkowości/wieloprocesorowości

Witam. Niestety nie rozróżniam wielowątkowości/wieloprocesorowości w bash
Jak uruchomię ten plik np. jako skrypt.sh uzytkownik_jeden to działa lecz jak uruchomię jako skrypt.sh linux_jeden to już nie. Chce poprostu, żeby funkcje t1-t12 wykonywały się równolegle w podpowłokach w celu oszczędności czasu. Korzystałem z tego https://technoglitz.com/poland/wykorzystanie-...ielowatkowego-w-skryptach-bash-cloudsavvy-it/
Funkcja linux_jeden nie zwraca zmiennych do głównego skryptu i on kończy błędem skrypt.sh: line 1252: [: too many arguments, jak to naprawić ?

Po zgrubnym przescrollowaniu Twojego skryptu poleciłbym rozpocząć od ustawienia bash-strict-mode:

Przepuścić skrypt przez shellcheck.
Oraz zapoznać się z google-shell-style-guide.

Teraz odpowiadając najpierw na: "Chce poprostu, żeby funkcje t1-t12 wykonywały się równolegle w podpowłokach", powinno zadziałać coś takiego:



Jeśli jakaś funkcja zostanie uruchomiona w sub-shell, to ów sub-shell będzie miał kopię wszystkich zmiennych (środowiskowych), czyli jak funkcja powiedzmy t6 zmodyfikuje / ustawi jakąś zmienną, to w funkcji koniec ona nie będzie ustawiona.
Komunikacja między procesowa to szeroka dziedzina, najłatwiej przeskoczyć to w taki sposób, że efekt pracy funkcji t6 zapiszesz do pliku t6.out i w funkcji koniec go odczytasz.
Możesz też zrobić takie mini uproszczenie, że format pliku będzie też bash-em i będziesz zapisywał zmienne, czyli:

stelmluk napisał:

Witam. Niestety nie rozróżniam wielowątkowości/wieloprocesorowości w bash

Wieloprocesorowość to możliwość wykorzystania wielu rdzeni/cpu jednocześnie, ale to domena systemu operacyjnego
Współbieżność to możliwość wykonania wielu procesów/wątków jednocześnie na 1 lub wielu rdzeniach. Gdy jest dostępny tylko 1CPU co 1ms będzie przydzielany czas kolejno dla jednego wątka sprawiając wrażenia użytkownikowi, jakby miał wiele procesorów.

Wątki znane z C (threads) w bashu nie występują. Gdy uruchamiasz funkcję z "&" to tworzony jest nowy proces, widoczny w systemie pod nowym numerem. Bash wywołuje funkcję "fork()" i ona duplikuje stos i pamięć danych, powodując że np. zmienne globalne widoczne w funkcji to są różne komórki w pamięci fizycznej. Żeby wymieniać dane między procesami trzeba używać kolejek (pipe), plików, gdniazdek, sygnałów, itd.

W C/C++ i innych występują wątki lekkie (threads), które mają tą samą przestrzeń danych, więc jak jeden wątek pisze do zmiennej to drugi od razu tą zmianę widzi. W rzeczywistości, żeby sobie nie wchodziły w paradę to trzeba stosować semafory/muteksy/monitory/etc.

Tak się zastanawiam, czy nie lepiej by było użyć jakiś inny język? Wydaje mi się, że w innych językach było by łatwiej, ale to tylko takie moje wrażenie.

Dziękuje za podpowiedzi. jvoytech moim zdaniem łatwiej by było użyć innego języka lecz ja z pewnych względów potrzebuje to w bash. Swoją drogą dziękuje też za omówienie wielowątkowości. Damian_Max dziękuję. Twoja odpowiedź rozwiązuje mój problem. Ja myślałem, że coś źle robię, a to niestety ograniczenia bash powodują, że z podporcesu do procesu głównego nie docierają zmienne. Może jeszcze jedno pytanko uda mi się przemycić. Skrypt ryje dysk co jakieś 5-6 sekund czy może to być spowodowane małą ilością ramu? Jeśli nie to gdzie w nim problem?

Jakby była możliwość użycia np. Redis ("sudo apt-get install redis-server redis-tools"), to można zrobić prostą komunikację między procesami. Np. jeden proces może ustawić zmienną:

a inny proces może sobie ją w dowolnym czasie odczytać:

Jeśli podprocesy mają coś przekazywać do głównego shella, to może użyć nazwanego pipe, do którego każdy podproces będzie pisał, a główny shell będzie go czytał? Tylko uwaga: pipe musi być stale otwarty do czytania, inaczej przy pisaniu wystąpi błąd; poza tym, zamknięcie przez ostatniego piszącego powoduje odczytanie końca pliku, więc jeśli piszący mają otwierać pipe dla pojedynczych wpisów i zaraz zamykać, to potrzebny jest dodatkowy proces, który będzie miał ten pipe stale otwarty do pisania.

Test działania tego sposobu ("cat p" zastępuje czytanie):