Programiranje u C++-u - pitanja i odgovori

Zašto se ne bi smio? Sve standradne biblioteke se smiju koristiti na natjecanju. Na državnom čak, na natjecateljskom računalu, bude cijela referenca STL-a dostupna tijekom natjecanja.

Pa zar je problem tu funkciju napisati ako baš i ne smije koristiti onu iz standardne biblioteke?

int max(int a, int b)
{
    if (a<b)
        return b;
   
    return a;
}

Velik posao :D

Trebam primjer programa za "ovu nit vrti na ovoj jezgri". Nešto jednostavno (npr ispis Hello world ili slično), ali da pravilno koristi SetThreadAffinityMask i/ili ThreadIdealProcessor.

Može i nekakvo računanje ili nešto, glavno da optereti samo jednu jezgru i to ne prvu nego da mu je u programu definirano koju.

Problem je što ne pronalazim nigdje nekakav osnovni primjer, nešto elementarno. A treba mi. Hvala.

SetThreadAffinityMask prima dva parametra. Prvi je handle od threada čiji affinity mask pokušavaš mijenjati, a drugi parametar je dword (32 bitni integer), koji predstavlja masku bitova.

Recimo da imaš slijedeću masku:

00000000000000000000000000001101

Thread je označen da se može vrtiti samo na prvoj, trećoj i četvrtoj jezgri.

Ili za:

00000000000000000000000000001001

Tada samo na prvoj i četvrtoj jezgri.

Naravno, ti se brojevi tako ne pišu, to je samo vizualizacija da zamisliš bitove unutar integera kao on/off switcheve (tj. takozvane zastavice odnosno flags). Prvi broj je zapravo 13, a drugi broj je 9.

Nikako. Ne postoji windows API funkcija IskoristiJezgruStoposto. Ti možeš izvršavati određeni programski kod na nekoj od jezgri te time uzeti zauzeti određeni postotak procesorskog vremena. Koliki? To je posve prepušteno tebi. OS ti omogućava stvaranje threadova, dodjeljivanje threadova određenim jezgrama i postavljanje prioriteta svakom threadu, dalje si prepušten sam sebi...

GetSystemInfo kojem proslijediš pointer na SYSTEM_INFO strukturu kao parametar. Nakon toga iz te strukture čitaš ono što te zanima.

Joj, imaš 3 definirane funkcije i jednu petlju. Osim WINAPI funkcija (čiji opis trebaš potražiti na MSDN-u), što ti tu ima biti nejasno?

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <stdio.h>

HANDLE *m_threads = NULL;
DWORD_PTR WINAPI threadMain(void *p);

DWORD_PTR GetNumCPUs()
{
    SYSTEM_INFO m_si = {0, };
    GetSystemInfo(&m_si);
    return(DWORD_PTR)m_si.dwNumberOfProcessors;
}

int main(int argc, wchar_t **args)
{
    DWORD_PTR c = GetNumCPUs();

    m_threads = new HANDLE[c];

    for (DWORD_PTR i = 0; i < c; i++)
    {
        DWORD_PTR m_id = 0;
        DWORD_PTR m_mask = 1 << i;

        m_threads[i] = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)threadMain, (LPVOID)i, NULL, &m_id);
        SetThreadAffinityMask(m_threads[i], m_mask);

        wprintf(L"Creating Thread %d (0x%08x) Assigning to CPU 0x%08x\r\n", i, (LONG_PTR)m_threads[i], m_mask);
    }

    return 0;
}

DWORD_PTR WINAPI threadMain(void *p)
{

    return 0;
}

Znam što je to, malo sam ga samo posložio i ovdje zalijepio da se vidi a ne da se mora klikati na link.

To su tipovi podataka definirani za uporabu u windows API funkcijama, običan typedef, ništa posebno ni zastrašujuće. Iako ih ima puno:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx

Često ne moraš uopće razbijati glavu time što se zapravo krije iza određenog tipa podatka, samo ih upikneš na prava mjesta tamo gdje se traže.

Ali evo u ovom konkretnom slučaju možeš vidjeti da se iza DWORD_PTR krije ULONG_PTR, e sada, da znaš takozvani hungarian notation odmah bi ti iz imena bilo jasno što je ULONG a što PTR, ali kako vjerojatno ne znaš potražiš na gornjoj listi ULONG_PTR i otkriješ da je riječ o "unsigned long" tipu podatka, što znači da je i DWORD_PTR zapravo "unsigned long".

_beginthread() i CreateThread() rade istu stvar, samo na malo različite načine:

http://support.microsoft.com/kb/104641/en-us

Tako da ni sa time ne moraš razbijati glavu, koja god od te dvije funkcije je u igri znaš da na tom mjestu nastaje novi thread.

Da si u google opalio WIN32_LEAN_AND_MEAN odmah bi ti sve bilo jasnije.

http://www.gamedev.net/topic/544437-what-does-define-win32_lean_and_mean-actually-do/

http://blogs.msdn.com/b/oldnewthing/archive/2009/11/30/9929944.aspx

Ništa posebno i ništa bez čega ne možeš. Ali se taj macro uvukao pod kožu ljudima koji često rade sa WINAPI-jem pa ga automatski stavljaju iako više i ne čini toliku razliku.

Učenje je na početku uvijek teško i naporno. Kada shvatiš osnovu WINAPI filozofije (a budeš nakon što ga duže budeš koristio), sve će ti postati jasno i logično...

A šta je sa predavanjima argumenata po referenci funkcijama?

Pa kada želiš da predaš argumente nekoj funkciji po adresi. Tj. ne predaš kao argument vrijednost nego adresu te funkcije u memorijskom bloku funkcije iz koje je ta varijabla.

Primjer:
#include<iostream>

using namespace std;

void ispisi_broj(int* broj)

{

   cout<<*broj<<endl;

}

int main()

{

   int n;

   cin>>n;

   ispisi_broj(&n);

   return 0;

}

Pa zato sto svaka funkcija ima svoj memorijski prostor. Ako zelis raditi sa istom varijablom u vise funkcija moras koristiti ili globalne varijable ili pokazivace. Kada predas adresu varijable funkciji tada ona radi sa tom adresom, odnosno tom vrjeenoscu na adresi koja nije u memorijskom bloku te funkcije.

I da, zaboravio sam reci, polja. Kada predajes polje funkciji kao argument, u biti joj predajes adresu prvog elementa u nizu. 

Ako imaš serijsko izvođenje tri različite radnje, što će ti tri threada za to? Uopće ne trebaš threadove...

Sve što trebaš je ovdje:

Process and Thread Functions

Time Functions

Ali mislim da si opet zagrizao više nego što možeš progutati...

Baš si se uhvatio multithreadinga i kojekakvih benchmarka, čovjek bi očekivao da ćeš do sada to već znati pjevati u snu. :S

Programer ne brine o threadovima već OS i to s razlogom. To je kao da u C++u koristiš assembler za deklaraciju varijable umjesto već postojećeg automatskog memorijskog managementa. Radije tu energiju iskoristi za nešto drugo.

Inače, thredovi se mogu izvršavati "paraleno" i paralelno. Pod navodnicima - thredovi se simultano jedan po jedan izvršavaju u istoj jezgri (svaki thread se izvršava određeni dio vremena pa to liči kao paralelno) dok stvarni paralelni rad je kada se thredovi izvršavaju u različitim jezgrama. Tu su još i različiti prioriteti thredova u ovisnosti o kojima procesor određuje koliko i kada se pojedini thread izvršava itd. Sve u svemu to nije nešto čime bi se ti trebao zamarati jer na kraju ćeš samo napraviti eventualnu pogrešku ukoliko to budeš pokušavao sam realizirati.

Da bi to učio na nižem nivou prethodno trebaš imati dobru teoretsku podlogu. Tek kada shvaćaš što se unutra događa i s kojim razlogom onda se može pričati o nekoj custom implementaciji i zašto bi ona imala smisla.

Ukratko, implementiraš primitivan CPU scheduler i baviš se tim područjem, tako reci ljudima...

OS sve to ima implementirano (automatski organizirano) i ne vidim čemu izmišljanje mlake vode. Usto, ne vidim što bi tom svom custom implementacijom postigao, ubrzao ili sl., a da ne govorim o problemima realizacije semafora ili kritičnih sekcija kod thredova takvog tipa.