Parallel.For - liczba wątków

Witam,

Kod jest taki:

class Program
    {
        static StreamWriter file = new StreamWriter("plik.txt");

        static void Main(string[] args)
        {
            
            Parallel.For(0, 100, new ParallelOptions() {MaxDegreeOfParallelism = 100 }, i => AddText(i));
            Console.WriteLine("Zamykam plik");
            file.Close();
           
        }

        static void AddText(int i)
        {
            Thread.Sleep(1000);
            lock (file)
            {
                file.WriteLine("Zapisałem: " + i.ToString());
            }
            Console.WriteLine(i);
            
        }
    }

Pytanie: dlaczego wykonyują się jednocześnie tylko 3 zadania? Dam ograniczenie do 1 - mam odopwiednik zwykłego for, ograniczenie do 2 - 2 zadania jednocześnie. Natomiast więcej niż 3 się nie da. Czy jest to jakieś odgórne ograniczenie i muszę sam obsłużyć tworzenie wątków w celu zwiększenia tego limitu?

Według dokumentacji, powinno tu być 100 zadań jednocześnie, a kod ma się wykonać w 1 sekundę + narzut.

[edit]
Hm doczytałem gdzieś, że to zależy od liczby rdzeni procesora. Jak więc wymusić większą liczbę wątków (oprócz tworzenia własnego TaskShedulera) ?

Według dokumentacji, powinno tu być 100 zadań jednocześnie, a kod ma się wykonać w 1 sekundę + narzut.
Gdybyś miał 100 rdzeniowy procesor, to owszem. Ale w przypadku np. 4 rdzeni można jednocześnie wykonywać tylko 4 zadania. Dodatkowo u Ciebie narzut jest dość duży - blokujesz plik, przez co jednocześnie nad nim może pracować tylko jeden wątek.

Owszem blokuję plik, bo tylko jeden wątek na raz moze do pliku pisać. Więc jeśli dobrze rozumiem, to nie może tu być więcej zadań niż jest rdzeni procesora?

Na to pytanie ciężko mi odpowiedzieć, ale może znajdziesz informacje tutaj: http://www.albahari.com/threading/part5.aspx

W sumie to mam tu procek 2 rdzeniowy, a wykonywane były 3 zadania. Więc nie wiem dalej jak to jest, ale zdaje się że ograniczenie to liczba rdzeni, bo cały ten framework powstał w celu łatwiejszego wykorzystania wielu rdzeni a nie jako zastępstwo dla tradycyjnego programowania z użyciem wielu wątków.

Zerknij na rozdział "Calling Blocking or I/O-Intensive Functions" w linku, który podał kuba. Nie jest to więc raczej ograniczenie frameworka.

Prawdopodobnie ograniczeniem jest ilość rdzeni + 1. Zresztą i tak więcej wątków nie ma sensu.

Do obliczeń nie ma sensu, do innych rzeczy (jak pobieranie lub wysyłanie plików na przykład) - ma sens.

Racja.

othello napisał(a)

Do obliczeń nie ma sensu, do innych rzeczy (jak pobieranie lub wysyłanie plików na przykład) - ma sens.

A to nie ThreadPool lepszy w takim przypadku?

No lepszy, ale chciałem liznąć trochę nowości.

Ostatnio chciałem się pobawić tą nową klasą w Mono i miałem podobny problem. O ile w .NET domyślny TaskScheduler sobie w miarę sensowny sposób określa ilość maksymalnych wątków i opiera się na ThreadPool, tak klasa Parallel w Mono jest spierdolona dokumentnie. Pojawiła się w Mono razem z wersją 2.8. Nie jest to żadna alpha, beta, RC. No i zastanawiałem się dlaczego identyczny kod na Windows wykonuje się 2.5 sekundy, a na Linuksie 10 (był wykonywany zupełnie sekwencyjnie). No to wchodzę sobie na IRC, jakieś kanały deweloperów Mono. Pytam o co chodzi.. czekam 15 minut, cisza. Ściągam źródła, szukam. Dmyślny TaskScheduler to klasa, która jako maksymalną ilość wątków zwraca ilość rdzeni, a reszta metod jedyne co robi to "return false". No dobra, ale gdzieś musi być ten kod. I jest! Cały kod, który powinien określać TaskScheduler jest w metodzie Parallel.For. Czyli możesz zrobić własny TaskScheduler, ale i tak nie będzie brany pod uwagę :D. Do tego w całej klasie kwiatki typu: komentarz nad metodą "// this is probably wrong..." i połowa metod rzuca NotSupportedException. Dzielę się swoim znaleziskiem na IRC. Nagle mi odpowiada jeden z operatorów "yeah, there might be some bugs, we'll fix it later". Patrzę teraz, wyszła nowa wersja, 2.8.1. Niestety w changelogu ani słowa o klasie Parallel.

@up - Mono jest w końcu Open Source - każdy może coś napisać - jeśli mu się chce (w tym przypadku nikomu się nie chciało poprawiać i Parallel został). Chyba o to chodzi w takich projektach?