C - ohjelmoijan ajatuksia.

Netlink soketit

2011-09-16T16:33:00.001+03:00

Netlink soketti rajapinta.

Viime keväänä sain tehtäväkseni laajentaa linux:n päälle tehdyn ohjelmistoalustamme IPv4 konfigurointituen koskemaan myös IPv6:tta. Kyseessä on siis reittien, aliasosotteiden, VLAN interfacejen jne konfigurointi. IPv4 osuus oli tehty pääosin linuxin ioctl rajapintaa käyttäen, mutta IPv6 tukea pohtiessani totesin tämän olevan riittämätön.

Pienen tutkinnan ja hutkinnan jälkeen, päädyin netlink soketti rajapinnan käyttämiseen. Man sivut ja useat muut lähteet kehoittivat käyttämään matalan tason netlink API:n sijasta libnl kirjastoa. Kääntelin libnl kirjaston omalle alustalleni, ja aloin tutkimaan miten se toimii. Jostain syystä libnl:n dokumentaatio ei kuitenkaan millään avautunut minulle. Aikani tuskailtuani löin hanskat tiskiin ja totesin että minun on keksittävä jokin toinen keino. Niinpä palasin takaisin raakaan netlink rajapintaan.

Netlink rajapinnalle löysin varsin kattavanoloisen dokumentaation man sivuista, sekä jopa RFC:n joka kuvasi netlink rajapinnan routtaus protokollan. Ei siis muuta kun hihat rullalle ja hommiin... Itse asiassa, perusjutut oli varsin suoraviivaisia, ja moni asia onnistui varsin kivuttomasti, jo pelkän pienen googlailun ja man sivujen tutkinnan perusteella. Lopulta kuitenkin törmäsin aukkoihin dokumentaatiossa, jotka lopulta pakottivat minut kääntämään oman debuggiprinteillä varustetun kernelin... Näitä aukkoja on tarkoitus paikata tässä blogitekstissä. Samalla luultavasti lisään oman pienen palaseni muuten rikkaaseen netlink sokettien perusdokumentaatioon - jota tosin voi olla vaikeaa löytää suomeksi??

Netlink socketit ovat itse asiassa enemmän kuin vain IP konfigurointien rajapinta. Ne ovat varsin geneerinen keino vaihtaa dataa user ja kernelspacen välillä. Netlink sockettien avulla voi myös mm. säätää palomuureja ja "neighbour cachea". Tässä blogissa keskityn kuitenkin vain kolmeen netlink sockettien viestityyppiin/konfiguroitavaan ominaisuuteen.

1. Linkkeihin (kuten eth0, vlan linkit kuten eth0.20 jne), jotka ovat ikäänkuin ovia systeemin ulkopuolelle / ulkopuolelta.
2. Osoitteisiin (kuten 192.168.255.2/24 tai fe80::211:43ff:fe26:2b6c/64), jotka ovat ikäänkuin lappuja ovissa, kertoen systeemin ulkopuolelle kuka oven takana on, ja systeemin sisäpuolelle, mihin ulkopuolelta pääsee.
3. Reitteihin, (kuten 0.0.0.0 via dev eth0, tai 10.34.143.0 255.255.255.0 gw 192.168.1.55 metric 2), jotka voivat osoitteiden lisäksi antaa erityisiä ohjeita siitä, mistä ovesta mihinkin kohteeseen matkalla oleva paketti täytyy potkaista menemään.

Nyt minulle tuli pakoittava tarve kertoa hiukan tarkemmin reiteistä. Saattaa olla, että Vesa ei ihan ymmärtänyt mitä tuo reitti tarkoittaa ;) Jos reitit on tuttua kauraa, tai eivät kiinnosta, niin ole hyvä ja skippaa neljä seuraavaa kappaletta.

Reittien ideana on sanoa, että "tällaiseen osoitteeseen matkalla oleva paketti täytyy tuupata tuosta interfacesta ulos". Jos palaamme stackissa muutaman rivin taaksepäin, huomaamme kohdan jossa kerroin osoitteen olevan ikäänkuin lappu siitä, mitä jonkin linkin (interfacen) takana on. Ts. jos eth0 linkkimme osoite on 192.168.255.2/24, tämä kertoo meille että oven (linkin) eth0 takana on "verkko" (osoitteet) 192.168.255.XXX. Miksi? Koska osoitteen loppuosa /24 kertoo ns netmaskin. Se siis kertoo että oven takana oleva verkko, johon siis meidänkin ovemme kuuluu, koostuu osoitteista joissa 24 ensimmäistä bittiä on kiinteitä, loppujen 8 vaihtuessa. Ts, 192.168.255 on verkkomme vakio-osa. Jokainen pisteiden välissä oleva numerosarja kun voi IPv4 osoitteessa vaihdella 0-255 välillä - Ts. muodostuu kahdeksasta bitistä. 4 tällaista osaa tarkoittaa 4*8 = 32 bittiä, joka siis on koko osoite. Esimerkissämme 24 ensimmäistä bittiä on kiinteitä, ts. kolme ensimmäistä numerosarjaa on kiinteitä. Jos maski olisi /23, tarkoittasi se että 23 bittiä olisi kiinteitä. Tällöin osoitteet verkossa voisivat olla 192.168.255.XXX tai 192.168.254.XXX /8 tarkoittaisi osoitteiden olevan 192.XXX.XXX.XXX jne.

Nyt siis osaamme ilman erillisiä reittejä jo sanoa, että osoitteeseen 192.168.255.66 matkalla oleva paketti, tulisi esimerkkitapauksessamme tuupata ovesta eth0 ulos. Mutta entäs jos meillä olisi useampi linkki (esim. useampi verkkokortti, tai vaikka VLAN virtuaali-interface) vaikkapa eth0 ja eth1, olkoot osoitteet vaikka 192.168.255.2/24 ja 192.168.1.2/24, ja pakettimme olisi menossa osoitteeseen 10.24.45.22? Nyt kummankaan linkin osoite ei kerro että linkin takaa löytyisi kyseinen kohde... Tarvitaan siis erillinen reititysohje kertomaan kummanko linkin kautta paketti tulee paiskata pihalle. Katsotaampa siis ensimmäistä esimerkkireittiä:

0.0.0.0 via dev eth0
0.0.0.0 on reitin kohde osoite. 0.0.0.0 on erikoisasemassa oleva osoite, ja kohdeosoitteena se siis tarkoittaa ns. oletusreittiä. Ts. kyseinen reitti kertoo, että mikäli mikään muu reititysohje ei paketin kanssa toimi, tulee se toimittaa eth0 linkkiin.

Toinen esimerkkireitti oli 10.34.143.0 255.255.255.0 gw 192.168.1.55 metric 2
Tässä kohdeosoite on 10.34.143.0, ja nettimaski on 255.255.255.0. Tämä tarkoittaa samaa kuin 255.255.255.0/24, eli maski kertoo merkitsevät numerot osoitteessa. Gw tarkoittaa gatewayta, joka kertoo, että paketti tulee toimittaa koneen 192.168.1.55 kautta, ja tuo kone tuntee tien lopulliseen määränpäähän. Metric 2 kertoo kuinka suosittu reitti on. Ts, mikäli johonkin osoitteeseen on määritetty useampi kuin yksi reitti, valitaan ensisijaisesti reitti jolla on tarkempi maski. Esim jos paketti on lähetetty osoitteeseen 192.168.255.124, ja reitteja on määritetty osoitteeseen 192.168.255.0 maskilla 255.255.255.0, sekä reitti osoitteeseen 192.168.255.124 maskilla 255.255.255.255, valitaan ensisijaisesti jälkimmäinen reitti, joka siis on tarkka. Ns. "hostireitti". Mikäli kuitenkin reittejä olisi kaksi vaihtoehtoista, eikä maskeissa olisi eroja, voidaan "suosituimmuus" määrittää metric arvolla. Mitä pienempi metric, sitä suositumpi reitti. Ts, paketti toimitetaan ennemmin pienemmän metricin omaavaan reittiin.

IPv6:n kanssa reititys on hieman monimutkaisempaa, sillä itse osoitteet kantavat osan aliverkkotiedosta. Mutta se reiteistä. Mennäänhän päivän epistolaan. Netlink rajapinta on siis tyypillinen viestirajapinta. Sockettiin lähetetään pyyntöjä, ja vastauksia kuunnellaan. Tässä jutussa käsittelen kolmen eri tyypin pyyntöjä/vastauksia - Osoite (ADDRESS), reitti (ROUTE) ja linkki (LINK). Kaikille perheille on määritelty viestityypit joilla voidaan

luoda uusi < osoite/linkki/reitti >
poistaa olemassaoleva < osoite/linkki/reitti >
hakea olemassaolevat < osoitteet/linkit/reitit >

Tarkat viestin headeriin täytettävät viestityypit ovat

RTM_NEWADDR (uusi osoite)
RTM_DELADDR (osoitteen poisto)
RTM_GETADDR (olemassaolevien osoitteiden haku)

RTM_NEWROUTE (uusi reitti)
RTM_DELROUTE (...poisto)
RTM_GETROUTE (...haku)

RTM_NEWLINK (uusi linkki)
RTM_DELLINK (...poisto)
RTM_GETLINK (...haku)

ja linkeille myös

RTM_SETLINK

jolla luodun linkin tilaa voidaan säätää.

Tässäpä minulle tulikin ensimmäiset ongelmat... Vasta kernelin koodeja tutkimalla opin, että NEWLINK reqiestit joissa struct ifinfomsg viestistructissa oli kenttiä täytetty - hylättiin.

Varsinainen netlink viesti koostuu:

1. normaali viestittelyssä käytetystä messuheaderista tyyppiä struct msghdr. Oletan että tämä on tuttu.
2. netlinkin messuheaderista tyyppiä struct nlmsghdr (alla)
3. viestityypistä (esim route, addres tai link) riippuva structi (tässä esitelty struct ifaddrmsg / struct ifinfomsg / struct rtmsg)
4. mahdollisesti sekalainen joukko atribuutteja.

Netlink message header
struct nlmsghdr
{
    __u32     nlmsg_len; /* Viestin pituus headeri mukaanlukien */
    __u16     nlmsg_type; /* Viestin tyyppi (kts. yllä) */
    __u16     nlmsg_flags;    /* Flagit */
    __u32     nlmsg_seq; /* Sequenssi numero */
    __u32     nlmsg_pid; /* Lähettävän processin portti ID */
};

1. Eli nlmsg_len siis kertoo koko viestin pituuden, karvoinen kaikkineen. Netlink viestien dynaamisten kokojen takia tämä kenttä on hyvin keskeinen.
2. Viestin tyyppi, esim RTM_NEWLINK.
3. Flagit...

...Suoraan /usr/include/linux/netlink.h:sta kaiveltuna/käänneltynä:

/* Flagit */

NLM_F_REQUEST        /* Viesti on requesti */
NLM_F_MULTI        /* Useampiosainen viesti, viimeinen tyyppiä NLMSG_DONE */
NLM_F_ACK         /* ack - viesti, sisältönä nolla tai virhekoodi */
NLM_F_ECHO         /* Pyyntö "echottaa" viesti */

/* GET requestin liput */
NLM_F_ROOT     /* palauta kaikki data, ei vain yhtä "entryä"*/
NLM_F_MATCH    /* palauta kaikki täsmäävät - todennäköisesti ei toteutettu */
NLM_F_ATOMIC     /* atominen "snapshotin" haku */
NLM_F_DUMP /* Dumppaa koko taulu */

/* NEW requestin liput */
NLM_F_REPLACE     /* Korvaa olemassaoleva */
NLM_F_EXCL     /* Älä koske jos on jo olemassa */
NLM_F_CREATE     /* Luo jos ei ole olemassa */
NLM_F_APPEND     /* Lisää listan hännille */

Esimerkiksi kaikkien pyyntöjen tulee olla varustettuna lipulla NLM_F_REQUEST. NLM_F_MATCH ei luultavasti ole toteutettuna, ja GET requestisi palauttanee kaikki mahdolliset reitit/linkit tai osoitteet jotka on tehtynä - riippumata niistä tarkennuksista joita requestisi structissa/atribuuteissa mainitsit. Lisätarkennusta flageihin saatat löytää man sivuilta.

4. sequenssinumero, joka auttaa parittamaan vastaukset oikeiden pyyntöjen kanssa - tyypillisesti juokseva numerointi (esim atomisesti kasvatettava globaali).
5. prosessin identifiointi. Tyypillisesti
(pthread_self() < < 16|getpid());
Kernelin vastauksissa pid on 0.

Huomaathan että oletusarvoisesti kerneli ei lähetä vastausta onnistuneisiin pyyntöihin (paitsi tietysti GET pyyntöihin). Minä kuitenkin haluan saada varmistuksen sille, että pyyntöni on kuultu. Siksi höystänkin kaikki muut paitsi GET requestini NLM_F_ACK lipulla. Tämä lippu saa kernelin vastaamaan muihinkin kuin GET pyyntöihin. Onnistunut suoritus kuitataan viestillä, jonka tyyppi on NLMSG_ERROR, ja jossa nlmsghdr structin perässä on struct nlmsgerr, jossa error kenttä sisältää arvon 0. Samaa viestiä kerneli käyttää raportoimaan virheet, mutta silloin error kenttä sisältää virhekoodin. Virhetilanteet raportoidaan NLM_F_ACK lipusta riippumatta.

struct nlmsghdr:n jälkeen seuraa requestikohtainen structi.

Osoitteille:

struct ifaddrmsg
{
    __u8        ifa_family;
    __u8        ifa_prefixlen; /* Prefixin pituus (maski)         */
    __u8        ifa_flags; /* Liput            */
    __u8        ifa_scope; /* Osoitteen skooppi        */
    __u32     ifa_index; /* Linkin ID numero (ifindex)          */
};

jossa ifa_family on siis IPv4 tilanteessa AF_INET, ja IPv6 tilanteessa AF_INET6.
ifa_prefixlen on maskin pituus bitteinä - IPv4 tapauksessa 0-32 ja IPv6 tapauksessa 0-128 (eli tämä siis kertoo millainen osoiteavaruus on sen interfacen takana, jonne linkki johon osoite on sidottu johtaa.
ifa_flags - liput

/* ifa_flags */
IFA_F_SECONDARY
IFA_F_TEMPORARY

IFA_F_NODAD
IFA_F_OPTIMISTIC
IFA_F_DADFAILED
IFA_F_HOMEADDRESS
IFA_F_DEPRECATED
IFA_F_TENTATIVE
IFA_F_PERMANENT

Joista en ole oikeastaan koskaan tarvinnut yhtään.

ifa_scope - "skooppi" - en oikeastaan ole jaksanut tutkia mitä tämä pitää sisällään. Tähänasti olen tyytynyt asettameen skoopin nollaksi.
ifa_index - sen linkin indexinumero johon osoite on sidottu. (kts man sivut funkkarille unsigned if_nametoindex(const char *ifname) jos tämä on outo juttu)

Linkit:

struct ifinfomsg
{
    unsigned char ifi_family;
    unsigned char __ifi_pad;
    unsigned short ifi_type;     /* ARPHRD_* */
    int     ifi_index;     /* Link index */
    unsigned    ifi_flags;     /* IFF_* flags */
    unsigned    ifi_change;     /* IFF_* change mask */
};

Kas niin. Murheenkryynini. Kuten jo mainitsin, hakkasin itse päätä seinään tekemällä RTM_NEWLINK requestin jossa struct ifinfomsg:n kenttiä oli täyteltynä. VLAN interfaceni luonti hylättiin tylysti kerta toisensa jälkeen.. Lopulta kernelikoodeja lukemalla tajusin, että NEWLINK requestissa ei oikeastaan saa olla mitään näistä täytettynä, vain attribuutteja kertomassa mitä oikeastaan yritetään. Myöhemmin linkin tilan voi muuttaa RTM_SETLINK requestilla. Itse käytin RTM_SETLINK:iä vain muuttamaan linkin tilan "ylös" tilaan (IFF_UP). Ja tämänkin tein laiskasti tuuppaamalla vain requestiin ifi_index kentäksi luodun linkin id:n, ifi_changen 0xffffffff:ksi (kuten man sivut neuvoo) ja ifi_flags kentän suoraan IFF_UP:ksi. Oikeampi tapa olisi varmaan ollut lukea linkin tila, ja sitten lisätä tai-operaatiolla (|) IFF_UP bitit lippuun.

Reitit:

struct rtmsg
{
    unsigned char     rtm_family;
    unsigned char     rtm_dst_len;
    unsigned char     rtm_src_len;
    unsigned char     rtm_tos;

    unsigned char     rtm_table; /* Routtaus taulun id */
    unsigned char     rtm_protocol; /* Routtaus protokolla (alla) */
    unsigned char     rtm_scope; /* skooppi (alla) */
    unsigned char     rtm_type; /* tyyppi (alla) */

    unsigned        rtm_flags;
};

Missä tyyppi voi olla:

    RTN_UNSPEC, /* määrittelemätön */
    RTN_UNICAST,        /* Gateway tai suora reitti */
    RTN_LOCAL,     /* Paikallinen      */
    RTN_BROADCAST,     /* Paikallinen bcast,
                 lähetä broadcastina */
    RTN_ANYCAST,        /* Hyväksy paikallisesti broadcastina,
                 mutta lähetä unicastina */
    RTN_MULTICAST,     /* Multicast reitti     */
    RTN_BLACKHOLE,     /* Tiputa paketit;          */
    RTN_UNREACHABLE,    /* Määränpää ei tavoitettavissa */
    RTN_PROHIBIT,     /* Pääsy kielletty */
    RTN_THROW,     /* Ei tässä taulussa        */
    RTN_NAT,        /* Muunna NAT:illa */
    RTN_XRESOLVE,     /* Käytä erillsitä paikannusta - ei mahda olla toteutettu    */

Luultavasti normaaleille reiteille haluat käyttää RTN_UNICASTia. Vaikkakin toisinaan spammin määrää ihmetellessä RTN_BLACKHOLEn käyttö olisi houkuttelevaa... ;)

Protokollat (kertovat siitä miten reitti on syntynyt):

#define RTPROT_UNSPEC 0 /* määrittelemätön */
#define RTPROT_REDIRECT 1 /* ICMP redirectien tekemä reitti;
                 Ei tällähetkellä IPv4:llä käytössä */
#define RTPROT_KERNEL 2 /* kernelin tekemä reitti        */
#define RTPROT_BOOT 3 /* bootissa tehty reitti      */
#define RTPROT_STATIC 4 /* Adminin tekemä reitti */

/*
Kerneli ei tutki protokollia > = RTPROT_STATIC;
*/

#define RTPROT_GATED    8 /* GateD */
#define RTPROT_RA 9 /* RDISC/ND router advertisements */
#define RTPROT_MRT 10 /* Merit MRT */
#define RTPROT_ZEBRA    11 /* Zebra */
#define RTPROT_BIRD 12 /* BIRD */
#define RTPROT_DNROUTED 13 /* DECnet routing daemon */
#define RTPROT_XORP 14 /* XORP */
#define RTPROT_NTK 15 /* Netsukuku */
#define RTPROT_DHCP 16     /* DHCP client */

Minä käytin arvoa RTPROT_STATIC, joka siis vastaa tilannetta jossa käyttäjä luo reitin käyttämällä komentoa "ip route add".

skoopit:

    RT_SCOPE_UNIVERSE=0,
/* User defined values */
    RT_SCOPE_SITE=200,
    RT_SCOPE_LINK=253,
    RT_SCOPE_HOST=254,
    RT_SCOPE_NOWHERE=255

Jos reittisi ei ole tarkoitettu paikalliseksi, lienee syytä käyttää RT_SCOPE_UNIVERSEa.

/* rtm_flags */

#define RTM_F_NOTIFY        0x100 /* Ilmoita jos reitti muuttuu */
#define RTM_F_CLONED        0x200 /* Kloonattu reitti     */
#define RTM_F_EQUALIZE     0x400 /* Multipath equalizer: NI */
#define RTM_F_PREFIX        0x800 /* Prefix addresses     */

Minä asetin liput nollaksi - en siis tarvinnut näitä omassa käytössäni.

Nyt viestimme siis koostuu netlink headerista, jossa ilmoitetusta tyypistä riippuen meillä on viestissä tyyppikohtainen strukti. Jotta homma ei jäisi liian simppeliksi, lisätään hieman muuttuvia osasia.. =)

Attribuutit.

Viestin loppuun voidaan lisätä sekalainen joukko attribuutteja joilla tarkennetaan luotavan/poistettavan reitin/linkin/osoitteen ominaisuuksia. Attribuutit alkavat structilla:

struct rtattr
{
    unsigned short rta_len;
    unsigned short rta_type;
};

jossa siis kerrotaan attribuutin koko, ja tyyppi. Structin jälkeen on varsinainen attribuutin data, jota siis on rta_len-sizeof(struct rtattr) verran. Attribuutit on vielä alignoitu 4:n tavun mukaan. Kuten C-koodari äkkiä huomaa, tällaisesta virityksestä saattaa tulla sekavahko hanskattava. Siksipä meillä onkin valmiit makrot attribuuttien hanskaukseen:

RTA_ALIGN(len)
RTA_OK(rta,len)
RTA_NEXT(rta,attrlen)
RTA_LENGTH(len)
RTA_DATA(rta)
RTA_PAYLOAD(rta)

RTA_ALIGN(len) Pyöristää annetun pituuden neljän tavun alignmenttiin. (Miten tuo sanotaan suomeksi???) Eli siis
RTA_ALIGN(1) palauttaisi 4 kuten myös RTA_ALIGN(4). RTA_ALIGN(5) taas palauttaisi 8 jne.

RTA_OK(rta,len) tarkastaa että annettu attribuutti rta on Ok. Yleinen tapa läpikäydä viestijonon attribuutit on hakea aina seuraava attribuutti makrolla RTA_NEXT, ja tarkistaa että atribuuttia on turvallista tutkia, kutsumalla RTA_OK:ta. Makroille annettavan pituuden (len), on ensimmäisellä kutsulla oltava attribuuttibufferin koko. Jokaisella RTA_NEXT kutsulla kokoa päivitetään.

RTA_LENGHT(len) palauttaa koon, joka tarvitaan jotta voidaan muodostaa atribuutti jonka datan koko on len. Eli RTA_LENGHT siis lisää annettuun kokoon struct rtattr:n koon ja alignoi sen sitten neljän tavun mukaiseksi.

RTA_DATA(rta) palauttaa pointterin attribuutin rta datan alkuun.
RTA_PAYLOAD(rta) palauttaa attribuutin rta sisältämän datan pituuden.

Kuulostaa sekavalta? Älä huoli, näytän myöhemmin esimerkin jolla attribuutteja voi läpikäydä.

Nyt kun selvät asiat on läpikäyty, voidaan mennä seikkaan joka sai minun hermoni melkein riekaleiksi.. Tieto siitä miten netlink sokettien avulla tehdään VLAN interface, eli virtuaalinen linkki joka lähettää VLAN tagilla varustettuja paketteja, ei löytynyt ihan helpolla. Google lauloi kun etsin:
"VLAN interface netlink sockets", "RTM_NEWLINK VLAN". "Create VLAN via netlink". "VLAN netlink attribute"... Näillä hauilla löysin tarpeeksi tietoa kertomaan, että kyllä - VLAN linkin pystytys on ilmeisesti mahdollista, ja että se onnistunee jollain attribuutilla... No lopullinen selvuus löytyi lisäämällä debuggiprinttejä kerneliin, ja yrittämällä & erehtymällä. Eli tavanomaisten attribuuttien lisäksi on ns. nested attribuutteja, eli sisäkkäisiä attribuutteja. Mutta katsellaanpa tuota myöhemmin.

Attribuutit joita eri requestit tukevat:

Osoitteet:
nbsp;   IFA_UNSPEC,
    IFA_ADDRESS,
    IFA_LOCAL,
    IFA_LABEL,
    IFA_BROADCAST,
    IFA_ANYCAST,
    IFA_CACHEINFO,
    IFA_MULTICAST,

Reitit:

    RTA_UNSPEC,
    RTA_DST,
    RTA_SRC,
    RTA_IIF,
    RTA_OIF,
    RTA_GATEWAY,
    RTA_PRIORITY,
    RTA_PREFSRC,
    RTA_METRICS,
    RTA_MULTIPATH,
    RTA_PROTOINFO, /* no longer used */
    RTA_FLOW,
    RTA_CACHEINFO,
    RTA_SESSION, /* no longer used */
    RTA_MP_ALGO, /* no longer used */
    RTA_TABLE,

Linkit:

    IFLA_UNSPEC,
    IFLA_ADDRESS,
    IFLA_BROADCAST,
    IFLA_IFNAME,
    IFLA_MTU,
    IFLA_LINK,
    IFLA_QDISC,
    IFLA_STATS,
    IFLA_COST,
    IFLA_COST
    IFLA_PRIORITY,
    IFLA_PRIORITY
    IFLA_MASTER,
    IFLA_MASTER
    IFLA_WIRELESS,
    IFLA_WIRELESS
    IFLA_PROTINFO,
    IFLA_PROTINFO
    IFLA_TXQLEN,
    IFLA_TXQLEN
    IFLA_MAP,
    IFLA_MAP
    IFLA_WEIGHT,
    IFLA_WEIGHT
    IFLA_OPERSTATE,
    IFLA_LINKMODE,
    IFLA_LINKINFO,
    IFLA_LINKINFO
    IFLA_NET_NS_PID,

osaan löydät dokumentaation rtnetlinkin man sivuilta sektiosta 7 - osaan et...

Ja nyt helpotukseksi heille jotka taistelevat VLAN linkkien teon kanssa... Minä sain VLAN linkin pystytettyä seuraavien attribuuttien avulla.

IFLA_LINK, datan koko on intin verran. Sisältää VLANin alla olevan oikean interfacen indexin.
IFLA_IFNAME, uuden VLAN linkin nimi. Itse käytin muotoa < alkuperäinen_interface > . < vlan Id >

sisäkkäiset attribuutit:
IFLA_LINKINFO joka siis sisältää
    attribuutin IFLA_INFO_KIND, jossa datans stringi 'vlan', pituuden ollessa tekstin 'vlan' pituus + 4:n tavun alignointi.
    toinen nested attribute IFLA_INFO_DATA, joka sisältää:
        attribuutin IFLA_VLAN_ID, jossa datana 16-bittinen vlan id.

Sekavan kuulosita? Jep.. Toisinaan ihmettelen onko insinöörit todella olleet NOIN humalassa speksatessaan rajapintoja... (http://xkcd.com/323/)

No helpotuksena(?) pätkä koodia jolla atribuutit voi hanskata (pahoittelut kielestä - en jaksa ainakaan nyt kääntää suomeksi, jos joku muu viitsii, niin otan kiitollisena päivitetyn koodin vatsaan! (kommenttina tai osoitteessa Mazziesaccount@gmail.com)

#define NLMSG_BOTTOM(nlmsg) ((struct rtattr *)(((void *)(nlmsg)) + NLMSG_ALIGN((nlmsg)- > nlmsg_len)))

static int addAttr(struct nlmsghdr *nl_req, int attrlabel, const void *data, int datalen)
{
    struct rtattr *attr=NLMSG_BOTTOM(nl_req));
    unsigned int attrlen=RTA_LENGTH(datalen); /* sizeof(struct rtattr) + datalen + align */
    if(NULL==nl_req || (datalen > 0 && NULL==data))
    {
        printf("NULL arg detected!");
        return -1;
    }
    attr- > rta_type=attrlabel;
    attr- > rta_len=attrlen;
    memcpy(RTA_DATA(attr),data,datalen);

    nl_req- > nlmsg_len=NLMSG_ALIGN(nl_req- > nlmsg_len)+RTA_ALIGN(attrlen);
    return 0;
}

static struct rtattr * addNestedAttr(struct nlmsghdr *nl_req, int attrlabel)
{
    struct rtattr *nested = NLMSG_BOTTOM(nl_req);

    if(!addAttr(nl_req, attrlabel, NULL, 0))
        return nested;
    return NULL;
}

static void endNestedAttr(struct nlmsghdr *nl_req, struct rtattr *nested)
{
    nested- > rta_len = (void *)NLMSG_BOTTOM(nl_req) - (void *)nested;
}

/* ...snip - Add attributes to the nlmsg msg */

        struct rtattr *attr1, *attr2;
        if(addAttr(msg,IFLA_LINK,&orig_ifindex,sizeof(int)))
        {
            printf("IFLA_LINK %d adding as rtattr to req failed!",orig_ifindex);
            retval=-1;
        }
        else if(addAttr(msg,IFLA_IFNAME,ifname,strlen(ifname)))
        {
            printf("IFLA_IFNAME %s adding as rtattr to req failed!",ifname);
            retval=-1;
        }
        else if(NULL==(attr1=addNestedAttr(msg,IFLA_LINKINFO)))
        {
            printf("addNestedAttr IFLA_LINKINFO FAILED!");
            retval=-1;
        }
        else if(addAttr(msg,IFLA_INFO_KIND,"vlan", strlen("vlan")))
        {
            printf("IFLA_INFO_KIND \"vlan\" adding FAILED!");
         retval=-1;
        }
        else if(NULL==(attr2=addNestedAttr(msg,IFLA_INFO_DATA)))
        {
            printf("addNestedAttr IFLA_INFO_DATA FAILED!");
            retval=-1;
        }
        else if(addAttr(msg,IFLA_VLAN_ID,&vlanid,sizeof(unsigned short)))
        {
            printf("IFLA_VLAN_ID %hu adding as rtattr to req failed!",vlanid);
            retval=-1;
        }
        else
        {
            endNestedAttr(msg,attr2);
            endNestedAttr(msg,attr1);
            printf("VLAN ID %hu, orig ifindex %d and new ifname %s added as attrs",vlanid,orig_ifindex,ifname);
        }

Tämä koodi olettaa että nlmsghdr structissa oleva viestin pituus on ajantasalla. Ts, ensimmäistä atribuuttia lisättäessä, pituuden on oltava nlmsghdr struktin koko + requesti spesifisen structin koko. Jokainen attribuutin lisäys kutsu edelleen päivittää tätä pituuskenttää. (kts. makro NLMSG_BOTTOM() )

Nyt alkaa tämän lyhyen intron loppu häämöttää. Esitän vielä oikeaa/pseudokoodia jotta messujen lähetyksen/vastaanoton idea tulisi selväksi.

struct sockaddr_nl kernproc;
struct msghdr msg;
struct nlmsghdr *netlinkresp;
struct iovec iov;

memset(&msg,0,sizeof(msg));

memset(&kernproc,0,sizeof(kernproc));
memset(&iov,0,sizeof(iov));

kernproc.nl_family = AF_NETLINK;

msg.msg_name=(void *)&kernproc;
msg.msg_namelen=sizeof(kernproc);

netlinkresp= < vastaukselle allokoitu bufferi > ;

/* Lisää NLMSG_F_ACK jos vastausta ei ole odotettavissa */

iov.iov_base=(void *)netlinkresp;
iov.iov_len= < nlmsg_len > ;

msg.msg_iov=&iov;
msg.msg_iovlen = 1; /* vain yksi iov structi */
iov.iov_len= < vastausbufferin koko >

retry:
    retval=recvmsg(sock, &msg, 0);
    if(0 > =retval)
    {
        if(errno==EINTR)
            goto retry;
        else
        {
            printf("Error when receiving from netlink sock!");
            /* handle error */
        }
    }
    else
    {
        /* ...reply received */
    }

Siis
1. Tarkista vastauksen pituus recv:n paluuarvosta - älä ylitä sitä.
2. Tarkista msghdr (EI SIIS nlmsghdr) nähdäksesi sopiko koko viesti vastaanottobufferiin.
    if(msg.msg_flags&MSG_TRUNC)
     ... varaa lisää tilaa ja yritä uudelleen...
3. Tallenna pointteri nlmsghdr messun headeriin.
4. aloita silmukka ja tarkista että messu on ok NLMSG_OK() makrolla. Jos ei, sinulla ei ole mitään hanskattavaa.
5. Tarkista nlmsg:n tyyppi, ja pituus. jos pituus on pidempi tai yhtäsuuri kuin nlmsg+tyyppi specifinen headeri, käytä
NLMSG_DATA makroa saadaksesi pointterin varsinaiseen messuun. Castaa ja tallenna pointteri.
5. Tarkista informaatio jota olit vailla. jos koko messu ei ole vielä käsitelty (pituus), silloin perässä on todennäköisesti attribuuttijoukkio...
6. Ota pointteri ensimmäiseeb attribuuttiin lisäämällä messu spesifisen structin koko to NLMSG_DATA();n palauttamaan osoittimeen.
7. aloita silmukka ja tarksista atribuutti RTA_OK() makrolla. Jos testi epäonnistuu, hyppää kohtaan 9
8. Tarkista attribuutin tyyppi ja data.
RTA_NEXT - > lopeta silmukka ja hyppää kohtaan 7.
9. Kun viimeinen attribuutti on tarkistettu, katso onko lippu NLM_F_MULTI asetettu nlmsghdr headerissa, ja että onko viimeisen viestin tyyppi NLMSG_DONE jos ei, hae seuraava nlmsg makrolla NLMSG_NEXT() ja hyppää uudelleen silmukkaan kohtaan 4

Viestin lähetys käyttää samaa generistä iovec mekanismia:

    struct sockaddr_nl kernproc;
    struct msghdr msg;
    struct nlmsghdr *netlinkreq;
    struct iovec iov;

    memset(&msg,0,sizeof(msg));this- > mypid

    memset(&kernproc,0,sizeof(kernproc));
    memset(&iov,0,sizeof(iov));

    kernproc.nl_family = AF_NETLINK;

    msg.msg_name=(void *)&kernproc;
    msg.msg_namelen=sizeof(kernproc);

    netlinkreq= < pointteri varattuun ja täytettyyn viestiin > ;

    netlinkreq- > nlmsg_pid= (pthread_self() < < 16|getpid());
    netlinkreq- > nlmsg_seq= atomicallyIncrementSeqId(seqid);

    #ifdef debug
    debugprint_msg(netlinkreq);
    #endif

    iov.iov_base=(void *)netlinkreq;
    iov.iov_len=netlinkreq- > nlmsg_len;

    msg.msg_iov=&iov;
    msg.msg_iovlen = 1; /* vain yksi iov struct */

    retval =sendmsg(sock,&msg,0);
    if(retval < =0)
    {
        printf("sendmsg() FAILED!");

    }
    return retval;

Debuggiprinttifunktioni läpikäy lähetettävän viestin seuraavalla koodilla:

    if(netlinkreq- > nlmsg_flags & NLM_F_ACK)
    {
        printf("Msg contains f_ack!");
    }
    if(!NLMSG_OK(netlinkreq,netlinkreq- > nlmsg_len))
    {
        printf("Looks like we're sending invalid nlmsg!! NLMSG_OK() == false at send!");
    }
    else
    {
        printf
        (
            "sending NLMSG: len %u, type %hu, flags %hu, seq %u pid %u",
            netlinkreq- > nlmsg_len,
            netlinkreq- > nlmsg_type,
            netlinkreq- > nlmsg_flags,
            netlinkreq- > nlmsg_seq,
            netlinkreq- > nlmsg_pid
        );
        switch(netlinkreq- > nlmsg_type)
        {
            case RTM_NEWROUTE:
            case RTM_DELROUTE:
            case RTM_GETROUTE:
            {
                printf
                (
                    "Req is route req (new %u, del %u, get %u)",
                    RTM_NEWROUTE,
                    RTM_DELROUTE,
                    RTM_GETROUTE
                );
                printf
                (
                    "family %u, dstlen %u, srclen %u, tos %u, table %u, proto %u, scope %u, type %u, flags %u",
                    (unsigned int)((struct rtmsg *) NLMSG_DATA(netlinkreq) )- > rtm_family,
                    (unsigned int)((struct rtmsg *) NLMSG_DATA(netlinkreq) )- > rtm_dst_len,
                    (unsigned int)((struct rtmsg *) NLMSG_DATA(netlinkreq) )- > rtm_src_len,
                    (unsigned int)((struct rtmsg *) NLMSG_DATA(netlinkreq) )- > rtm_tos,
                    (unsigned int)((struct rtmsg *) NLMSG_DATA(netlinkreq) )- > rtm_table,
                    (unsigned int)((struct rtmsg *) NLMSG_DATA(netlinkreq) )- > rtm_protocol,
                    (unsigned int)((struct rtmsg *) NLMSG_DATA(netlinkreq) )- > rtm_scope,
                    (unsigned int)((struct rtmsg *) NLMSG_DATA(netlinkreq) )- > rtm_type,
                    (unsigned int)((struct rtmsg *) NLMSG_DATA(netlinkreq) )- > rtm_flags
                );
                {
                    int len=netlinkreq- > nlmsg_len;
                    struct rtattr *at=(struct rtattr *)((char *)NLMSG_DATA(netlinkreq)+sizeof(struct rtmsg));
                    while(NULL!=at && RTA_OK(at,len))
                    {
                        char tmp[100];
                        switch(at- > rta_type)
                        {
                            case RTA_DST:
                                printf
                                (
                                    "dst is set to %s",
                                    inet_ntop
                                    (
                                        (at- > rta_len > 8)?AF_INET6:AF_INET,
                                        RTA_DATA(at),
                                        tmp,
                                        100
                                    )
                                );
                                break;
                            case RTA_SRC:
                                 printf
                                (
                                    "src is set to %s",
                                    inet_ntop
                                    (
                                        (at- > rta_len > 8)?AF_INET6:AF_INET,
                                        RTA_DATA(at),
                                        tmp,
                                        100
                                    )
                                );
                                break;
                            case RTA_GATEWAY:
                                printf
                                (
                                    "gw is set to %s",
                                    inet_ntop
                                    (
                                        (at- > rta_len > 8)?AF_INET6:AF_INET,
                                        RTA_DATA(at),
                                        tmp,
                                        100
                                    )
                                );
                                break;
                            case RTA_OIF:
                                printf
                                (
                                    "OIF is set to %u",
                                    *(unsigned int *)RTA_DATA(at)
                                );
                                break;
                            case RTA_PRIORITY:
                                printf
                                (
                                    "Priority is set to %u",
                                    *(unsigned int *)RTA_DATA(at)
                                );
                                break;
                            default:
                                printf("rta_type %u, len %u",at- > rta_type,at- > rta_len);
                                break;
                        }
                        at=RTA_NEXT(at,len);
                    }
                }
                break;
            }
            case RTM_NEWADDR:
            case RTM_GETADDR:
            case RTM_DELADDR:
                printf
                (
                    "Req is ADDR req (new %u, del %u, get %u)",
                    RTM_NEWADDR,
                    RTM_DELADDR,
                    RTM_GETADDR
                );
                printf
                (
                    "ifa_family %u, ifa_prefixlen %u, ifa_flags %u, ifa_scope %u, ifa_index %d",
                    (unsigned int)((struct ifaddrmsg *) NLMSG_DATA(netlinkreq) )- > ifa_family,
                    (unsigned int)((struct ifaddrmsg *) NLMSG_DATA(netlinkreq) )- > ifa_prefixlen,
                    (unsigned int)((struct ifaddrmsg *) NLMSG_DATA(netlinkreq) )- > ifa_flags,
                    (unsigned int)((struct ifaddrmsg *) NLMSG_DATA(netlinkreq) )- > ifa_scope,
                    (int)((struct ifaddrmsg *) NLMSG_DATA(netlinkreq) )- > ifa_index
                );
                {
                    int len=netlinkreq- > nlmsg_len;
                    struct rtattr *at=(struct rtattr *)((char *)NLMSG_DATA(netlinkreq)+sizeof(struct ifaddrmsg));
                    while(NULL!=at && RTA_OK(at,len))
                    {
                        char tmp[100];
                        switch(at- > rta_type)
                        {
                            case IFA_ADDRESS:
                                printf
                                (
                                    "IFA_ADDRESS is set to %s",
                                    inet_ntop
                                    (
                                        (at- > rta_len > 8)?AF_INET6:AF_INET,
                                        RTA_DATA(at),
                                        tmp,
                                        100
                                    )
                                );
                                break;
                            case IFA_LOCAL:
                                printf
                                (
                                    "IFA_LOCAL is set to %s",
                                    inet_ntop
                                    (
                                        (at- > rta_len > 8)?AF_INET6:AF_INET,
                                        RTA_DATA(at),
                                        tmp,
                                        100
                                    )
                                );
                                break;
                            case IFA_BROADCAST:
                                printf
                                (
                                    "IFA_BROADCAST is set to %s",
                                    inet_ntop
                                    (
                                        (at- > rta_len > 8)?AF_INET6:AF_INET,
                                        RTA_DATA(at),
                                        tmp,
                                        100
                                    )
                                );
                                break;
                            case IFA_LABEL:
                                printf
                                (
                                    "IFA_LABEL is set to '%s'",
                                    (char *)RTA_DATA(at)
                                );
                                break;
                            case IFA_ANYCAST:
                                printf
                                (
                                    "IFA_ANYCAST is set to %s",
                                    inet_ntop
                                    (
                                        (at- > rta_len > 8)?AF_INET6:AF_INET,
                                        RTA_DATA(at),
                                        tmp,
                                        100
                                    )
                                );
                                break;
                            default:
                                printf("rta_type %u, len %u",at- > rta_type,at- > rta_len);
                                break;
                        }
                        at=RTA_NEXT(at,len);
                    }
                }
                break;
.
./* Tänne voi lisätä uusia viestityyppejä */
        }
.
.
.

Tähän loppuu lyhyt introni netlink viestien maailmaan. Lisäinfoa löytyy mm. man sivuilta man 7 rtnetlink ja man 3 netlink

Jos sattuu että ĺöysit jotain hyödyllistä täältä, tai jos sinulla on jotain
parannusehdotuksia / suomenkielisiä koodiesimerkkejä, niin nakkaa minua
viestillä täällä tai osoitteessa Mazziesaccount@gmail.com

Ja jos käytät koodiani jossain, tai jos julkaiset sitä netissä, niin ole
ystävällinen ja mainitse minut (Maz) ja tämä sivusto lähteenäsi =)

Have fun!

Repositoryn muutos

2010-07-07T10:57:00.003+03:00

Hep Hep! Mikään ei ole niin pysyvää kuin muutos... Bottiprojektini juuttui jäihin ajanpuutteen vuoksi, ja repository on ammuttu alas. Viimeisimmät sorsat löytyy

http://xp-dev.com/svn/MazBotV4/trunk/

paketista.

Olen laajalti viljellyt linkkejä bottini svn repositoryyn, jossa säilön koodipätkiäni.
Jouduin tekemään joitain muutoksia repositoryyn, ja monet linkit vanhenivat. Seuraavalla muutoksella homman pitäisi taas pelata:

Vanha linkki kehitysrepon juureen:
http://blackdiam.net/svn/MazBot/

Uusi linkki:
http://blackdiam.net/svn/MazBot/trunc/

Ja stabiilimpi ympäristö:
http://blackdiam.net/svn/MazBot/releases/0.2.1/

Toivottavasti löydätte etsimänne ;)

-Maz

Lisää työkaluja C-koodina.

2010-06-29T14:53:00.012+03:00

13.09.2011: HepHep!
Sorsat saatavilla svn reposta http://xp-dev.com/svn/MazBotV4/trunk/
(generic/src kansiosta)

Kappas vain miten aika rientää. Edellisestä raapustelusta onkin mennyt jo tovi, mutta lohdutukseksi voin sanoa etten ole unohtanut kumpaakaan teistä rakkaista lukijoistani. :p

No nyt sitten tuli taas mieleen, että voisin jakaa noita räpellyksiäni myös muiden harmiksi. Tälläkertaa tiputetaan ilmoille muistin säästämiseksi tehdyt bittivektori ja pakattu taulukko.

Bittivektori:

Bittivektorilla tarkoitan tässäyhteydessä simppeliä tapaa säästää muistia. Oletetaan että meillä on liuta asioita, joilla on kaksi tilaa. Vaikkapa kouluaiheisena esimerkkinä oppilaiden koetulokset. Jokainen koe voi olla joko suoritettu tai suorittamatta. Ja koska nykypäivänä kaikki koetetaan sulloa samaan purkkiin, on oppilaita hirmuinen joukko.

Oletetaan nyt että olet tekemässä ohjelmaa, joka pitää kirjaa oppilaiden kokeiden suorittamisesta. Nopein mieleentuleva keino tallettaa tieto suureen taulukkoon, ja antaa oppilaille id-numero jolla taulukko voidaan indeksoida. Sovitaan nyt vaikka että oppilaita on 10000.

Ensimmäinen viritys voisi siis olla
int koe_suoritettuna[10000];
taulukko. Nyt pohditaan tovi. Kuka tietää kuinka monta bittiä int-tyypin tieto vaatii? Ei kukaan ;) Se on hieman konearkkitehtuurista riippuvaa.. Jos nyt otetaan esimerkkimasiinaksi intelin/amd:n x86 arkkitehtuuri, niin tyypillisesti int tietotyyppi vie 32 bittiä/luku. Eli yksi suorittamatta/suoritettu tieto vie siis 32 bittiä. Jos oikein asiaa ajatellaan, niin eihän tuon tiedon tallettamiseen tarvita kuin yksi bitti, joko 0(=suorittamatta) tai 1(=suoritettu). Eli jokaisen oppilaan kohdalla hukataan 31 bittiä tilaa. 10000 oppilasta => 310000 bittiä eli 38,750 tavua, eli n. 37.8 kilotavua.

No PC maailmassa tämä ei kuulosta pahalta, mutta kun vastaavat ratkaisut viedään sulautettuun ohjelmointiin, tai käsitellään vielä suurempia tietomääriä, alkaa softan muistinkulutus päästä M$:n tuotteiden tasolle...

Muistinkulutus saataisiin heti 4-kertaa pienemmäksi muuttamalla tietotyyppi chariksi. Mutta haluttaessa yhä optimaalisempaa muistinkulutusta, joudutaan rakentamaan jokin oma viritys. Tällainen on bittivektori. Bittivektorissa voidaan yksittäisiä bittejä varata tarpeellinen määrä (poislukien alignointibitit joilla ei yleensä näissä muistimäärissä ole merkitystä), ja muuttaa/lukea yksittäisen bitin arvo. Tähän tarkoitukseen koodailin bitsetin irc-bottiani varten.

Koodi löytyy bottini repositoriosta:
http://xp-dev.com/svn/MazBotV4/trunk/generic/src/
Tiedostot MbotBitset.h ja MbotBitset.c sisältävät bittivektorin. Pakattu taulukko on tiedostoissa MbotPackedArray.c ja MbotPackedArray.h

HUOM! Tämä bitsettiviritys ei ole koeponnistettu 64-bittisillä koneilla, enkä takaa sen toimivuutta moisessa ympäristössä. Mikäli kokeilet sitä 64-bittisellä arkkitehtuurilla, niin olethan ystävällinen ja raportoit tulokset vaikka kommentoimalla tätä blogia!

Pakattu taulukko:

No jos nyt jatketaan edellistä esimerkkiä kokeen suorittamisesta, niin phditaanpa hieman vnhanmallin yliopistoarvosanojen tallennusta. Eli kokeen suorittamisesta seuraa numero, ja numero tulee tietysti myös tallentaa. Numero voi kuitenkin olla muutakin kuin 1 tai 0. Wanhaan hyvään aikaan yliopistoissa arvosanat olivat hylätty, 1,2 tai 3.
Eli nyt yhden arvosanan esittämiseen tarvitaan kaksi bittiä.
(00) = hylätty
(01) = 1
(10) = 2
(11) = 3

Tällaiseen tarkoitukseen rakentelin bitsetin kaveriksi pakatun taulukon, joka kysyy suurimman mahdollisen tallennettavan luvun, ja laskee sen jälkeen tarvittavien bittien määrän && varaa muistin ja indeksoi sen sisäisesti oikean kokoisiin palasiin. Tämän jälkeen pakatusta taulukosta/taulukkoon voi lukea/kirjoittaa arvon halutulle oppilas-id:lle.

Pakattu taulukko löytyy samasta paikasta kuin bittivektori, mutta tiedostot ovat MbotPackedArray.h ja MbotPackedArray.c

Huom! pakattu taulukko on myös täysin testaamatta 64-bittisellä alustalla (ja oletuksena on ettei se toimi oikein 64-bit ympäristössä). Lisäksi 32 bittinen ympäristökin on hieman heikohkosti testattu...
Joten kaikki havainnot pyydetään raportoimaan.

Oh, ja sekä bitsetistä, että pakatusta taulukosta löydetyt bugit voi kirjailla minulle osoitteeseen Mazziesaccount@gmail.com / kommenttina tänne blogiposteihin.

(MazBot projektille)

-Maz

C on olio-ohjelmointi kieli! (osa 2)

2009-04-16T21:49:00.013+03:00

*********** EDIT ************
Kirjoituksen lopussa olevat koodit on nyt lisätty zippiin, jonka voit ladata sivun oikeasta sarakkeesta. (Koodi ei todellakaan ole luettavaa blogisivulla...)
*****************************

Jos joku teistä on lukenut Englanninkielistä blogiani, niin tämä juttu ei anna juuri lisää tietoa teille. Oikeastaan olen lisännyt vain lotto koodin joka löytyy aivan tekstin lopusta.

Vuosien saatossa minua on SUUNNATTOMASTI alkanut ärsyttää C++ ja JAVA koodareiden olio-ohjelmointi hypetys. Keskustelupalstat ovat täynnä teinipoikia, jotka kertovat siitä, miten C++ (tai JAVA) hakkaa C:n mennen tullen. Ja perusteluksi heille tuntuu riittävän se, että C++ ja JAVA ovat olio-ohjelmointikieliä.

Siis kertauksena: C++ koodarit tuppaavat uskomaan (ja tuputtamaan uskomustaan pahaa aavistamattomille aloittelijoille), että C++ on loistava kieli olio-ominaisuuksiensa takia, ja että C vastaavasti on huono kieli, koska se ei ole olio-ohjelmointiin soveltuva.

No nyt on korkea aika kertoa teille kaikille oliohypettäjille, että myös C tukee olio-ohjelmointia. Repikää siitä.

Lisäksi C on kaukana huonosta kielestä. Maailman ehkä parhaat ohjelmat kun on kirjoitettu C-kielellä, ja lisää C koodia tehdään edelleen päivittäin. Tiesitkö, että esim. Linux on kirjoitettu C:llä? Lisäksi suurin osa sulautettujen järjestelmien softista on tehty C:llä. Tiesitkö myös että nykyaikaisessa autossa lieenee saman verran koodirivejä kuin windows XP:ssä? Pelottava ajatus...

Joo, Vesa, koetahan ottaa happea, muutut pikkuhiljaa punaiseksi...

Te jotka juuri ja juuri putositte penkiltä järkytyksestä, ja olette jo lähdössä hakemaan erinäisiä teräaseita opettaaksenne minulle tapoja/oikaistaksenne harhaoppejani, miettikää ensin hetki, mitkä piirteet saavat ohjelmointikielestä oliokielen. Sillävälin minä haen kahvia...

Itse asiassa, C++:ssa on vain muutamia asioita, joita ei C:llä voi tehdä (syntaksi on tietysti erilainen. mutta samat ideat voidaan toteuttaa). Tärkeimpinä rajoituksina tulee mieleen operaattoreiden ylikuormaus, templatet ja destructorit. Näitä kun ei paljaalla C:llä oikein voi tehdä.

Mitä se Vesa huutelee? Ai raivoat jotain luokista, perinnästä ja virtuaalisuudesta? Otahan taas happea, kerron kohta.

Löysittekö muuten vastaukset kysymykseeni, että mikä tekee kielestä oliokielen? Tärkeimpinä piirteinä sanotaan olevan datan ja toiminnallisuuden paketointi samaan pakettiin, sekä instanssien luonti. (Ts. luokka joka kokoaa muuttujat ja funktiot, ja josta voidaan luoda mielin määrin instansseja.)

Englanninkielisestä blogistani kopioidut esimerkit menevät näin:

C++:


const int AGE_STOMACH_RATIO 5
class dog
{
private:
EColour furColour;
int age;
unsigned int stomach_state;
bool check_condition();
int calculateStomachCapacity();
void die();
public:
dog(EColour colour);
void feed(int food_amount);
};

dog::dog(EColour colour)
{
furColour=colour;
}

bool dog::check_condition()
{
if(calculateStomachCapacity() <
.
.
.

Ja vastaava C:llä:



struct Sdog;
int dog_check_condition(Sdog *_this);

typedef int (*check_conditionF)(Sdog *_this);
typedef int (*calculateStomachCapacityF)(Sdog *_this);
typedef void (*dieF)(void);
typedef void (*dogF)(Sdog *_this, EColour colour);
typedef void (*feedF)(Sdog *_this);
typedef struct Sdog
{
   EColour furColour;
   int age;
   unsigned int stomach_state;
   check_conditionF check_condition;
   calculateStomachCapacityF calculateStomachCapacity;
   dieF die;
   dogF dog;
   feedF feed;
}Sdog;

int dog_check_condition(Sdog *_this)
{
    //starvation or overeating
    if(_this-&ft;stomach_state == 0 ||
      _this->calculateStomachCapacity(_this) 
      <stomach_state 
    )
        return 0;
    return 1;
}
int dog_
void initDog(Sdog *_this, EColour colour)
{
   _this->furColour=colour;
   _this->age=1;
   _this->stomach_state=3;
   _this->check_condition=&dog_check_condition;
   .
   .
   .
   and so on..
}

Toivottavasti näette mitä ajan takaa :)

Mitenkäs sitten se seuraava, olio-ohjelmoinnin hiiiiieno paradigma? (Olen aina halunnut päästä käyttämään sanaa paradigma :) )

Instanssin luonti:

Nyt siis pitäisi voida tuosta dog "luokasta" kaulita haukkuja vaikka talon täydeltä...


int main()
{
  Sdog *lassie;

  lassie=malloc(sizeof(Sdog));
  lassie-&gtMdog=&initDog;
  *(lassie->dog)(lassie,EColor_brown);
  *(lassie->feed)(lasie,2);
  .
  .
  // or as a local variable:
  /*
  Sdog lassie;
  *lassie.dog=&initDog;
  *lassie.dog(&lassie,EColor_brown);
  *lassie.feed(&lassie,2);
  .
  .
  */

Hei Vesa, miksi noin hiljaa? Veikö koira kielen? ;)
Seuraavaksi sitten ehkä heikoimmin C:ssä toimiva OOP vaatimus,

tiedon "kapselointi":

Tässä on kyllä hieman huijauksen makua, mutta tarkoitushan olikin vain näyttää, että C:llä PYSTYY kirjoittamaan olioajatukset täyttävää koodia. Jaamme siis Sdog struktin kahteen osaan, julkiseen ja yksityiseen struktiin.



typedef struct Sdog
{
  dogF dog;
  feedF feed;
  char internalData[1];
}Sdog;

typedef struct S_dog
{
//As abowe.
}S_dog;

Nyt sijoitamme julkisen struktin esittelyn
(structin joka siis sisältää funktiot ja datan, jota oliomme
käyttäjän on päästävä käsittelemään), headeriin, joka tarjotaan
oliomme käyttäjälle. Privaatti structin taas esittelemme
headerissa, jota ei tarjota asiakkaallemme. .c tiedostossa
jossa otustamme sitten käsittelemme, inkuloimme molemmat
headerit. (Tai jos emme jaa oliomme toteutusta useampaan
tiedostoon, voimme jopa esitellä privaatti osat c-tiedostossamme,
ja tehdä funktioista sekä mahdollisista globaaleistamme staticeja
- silloin kapselointi toimii erinomaisesti).

Teemme siis dog_init() funktion, joka varaa tilan koiruudelle, ja
palauttaa osoittimen luotuun olioon käyttäjälle. Instanssia
tehtäessa siis allokoimme muistiköntin, johon sopii sekä public,
että privaatti struktit, ja sijoitamme ne peräkäin, siten että
julkinen osa tulee köntin alkuun. Käyttäjälle palautamme osoittimen
julkisen struktin alkuun. Tai voimme myös käyttää realloccia, ja
kasvattaa käyttäjän varaamaa oliota, mikäli emme halua lähteä
puhtaalle osoitinlinjalle.

placeholder[1] joka esimerkissä näkyy, on tehty helpoittamaan
struktin käyttöä. castaamalla osoittimen placeholderiin privaatti
struktiksi, pääsemme käsittelemään oikaa kohtaa ilman
laskutoimituksia.

Ai keksitkö Vesa jotain uutta, vai mikä noin hymyilyttää? Että
siis mitenkä C:llä hoidetaan...

Periytys:

Helppoa kuin heinän teko. Edellistä esimerkkiä jatkaakseni,
määrittelemme nyt structin Sdoberman, jonne sijoitamme
dobermannille ominaisen tiedon ja toiminnallisuuden. Yleiset
koiramatskut pidämme Sdogissa. Sitten edellisen esimerkin tapaan,
sijoitamme Sdoberman structin Sdog structin perään, ja lähestymme
asiaa osoittimin. Tahdottaessa käyttää geneerisiä koiramaisuuksia,
käytämme Sdog struktia, ja dobermannille ominaisissa asioissa
asioimme Sdobermannin kanssa. Eli osoitteiden laskentaa ja casteja.
Kyllä se siitä lähtee.

Ja vielä kuuluu Vesasta pihinää... Mitä...? Ok.

Virtuaali luokat:

Pysytään edelleen koiramaisissa tunnelmissa. Eli pidämme geneerisen
Sdog structimme, ja teemme lisäksi Sdoberman, Schihuahua ja
Ssekarotuinen struktit. Lisäämme geneeriseen struktiimme kentän,
joka kertoo minkätyyppinen koira on kyseessä (esim. enumin). Sitten
chihuahuaa, dobermannia tai sekarotuista luotaessa, täytämme
tyyppitiedon oikein. Kaikki kutsut tehdään jälleen Sdog struktia
käyttäen, mutta virtuaalitoiminnot suoritetaan Sdoberman, Schihuahua
ja Ssekarotuinen struktista, tyypin tarkistuksen ja oikean
castauksen jälkeen.

Vielä pari sanaa Destructoreista ja C:stä.

Oletko ikinä kuullut sanaa "memory pool"? Hyyyvin usein varsinkin
linux maailmassa, joudutaan köntti muistia allokoimaan johonkin
tarkoitukseen, ja jakamaan siitä palasia aina pyydettäessä.
Esimerkkinä olkoon vaikka jaettu muisti prosessien välillä, johon
siis päästään kirjoittamaan useammasta kuin yhdestä prosessista
yhtä aikaa. Tällöin on tarpeen pitää kirjaa siitä, mitkä palikat
muistista on milloinkin käytössä, ettei useampi prosessi kirjoittele
samaan kohtaan omia juttujaan.

Ehkä tyypillisin tapa tehdä tämä on:
1. Allokoida köntti.
2. jakaa se pienempiin palasiin, ja tehdä kirjanpito siitä, mitkä
palat ovat käytössä.

Käyttäjän pyytäessä muistia, lasketaan montako palasta käyttäjän
tarvitsema tila vie, etsitään vapaat palat ja merkitään ne
varatuiksi, kirjoitetaan ensimmäisen palan alkuun määrä jonka
käyttäjä varasi ja palautetaan käyttäjälle osoitin tämän "headerin"
(kirjanpidon) jälkeiseen muistiosoitteeseen. Käyttäjä sitten käyttää
muistia miten tahtoo, ja lopulta pyytää vapauttamaan muistin.
Vapautettaessa sitten tutkitaan käyttäjän antamaa "vapautettavaa
osoitetta" edeltävä paikka, johon kirjoitimme varatun määrän, ja
merkitsemme vastaavat palaset jälleen vapaiksi.

Nyt tähän sisäiseen kirjanpitoon voidaan lisätä tila
funktio-osoittimelle, ja antaa palan varanneen käyttäjän rekisteröidä
callback funktio, jonka osoite siis tallennetaan tähän headeriin.
Käyttäjän nyt pyytäessä muistipaikan vapautusta, suoritetaan samalla
Em. callback, ja voila. Meillä on destructoin tapainen ominaisuus
C:ssä. Tämä kuitenkin eroaa destructorista siinä, että mikäli
käyttäjä instantioi otuksensa stackista, eikä näinollen joudu sitä
erikseen vapauttamaan, me emme voi tehdä destructoria
(ainakaan helposti).

LottoEsimerkki:

Ja loppuun vielä esimerkki jonka tekaisin äkkipäätä väitteitäni
tukemaan. Hirveän kauhean inhottavan näköinen lottokötöstys-C-olio,
joka siis arpoo lottonumeroita. Ikävä kyllä, minulla ei ole mitään
muistikuvaa siitä, montako numeroa Viking lotossa oikeasti on, eikä
myöskään jokereiden määrästä, joten lotto-otukseni ei liene ihan
vastaa todellisuutta. (tosin defineitä muuttamalla siitä pitäisi
tulla toimiva ;) ) Ainoa julkinen (käyttäjälle tarkoitettu) headeri
on nyt lotto.h

Huom! Kapselointi paranisi mikäli peruslotto.c ja vikinglotto.c
olisi sisällytetty lotto.c tiedostoon, ja static avainsanaa olisi
käytetty näiden kanssa. Selkeyden vuoksi laitoin ne kuitenkin omiin
tiedostoihinsa, ja tein niistä siis globaaleja funktioita. Lisäksi
tilanne paranisi mikäli muista tiedostoista paitsi lottoTesti.c:stä
käännettäisiin kirjasto, ja käyttäjälle annettaisiin vain kirjasto
ja lotto.h headeri käyttöön.



/* ******************************************************** */
/*                                                          *
*      Implementation of a lotto engine written in C        *
*      Main purpose is to demonstrate that C can be used as *
*      object oriented programming language.               *
*                                                          *
*      Written by  Maz (2009)                              *
*      http://maz-programmersdiary.blogspot.com/           *
*      http://c-ohjelmoijanajatuksia.blogspot.com/         *
*                                                          *
*      You're free to use this piece of code.              *
*      You can also modify it freely, but if you           *
*      improve this, you must write the improved code      *
*      in comments at:                                     *
*      http://maz-programmersdiary.blogspot.com/           *
*      or at:                                              *
*      http://c-ohjelmoijanajatuksia.blogspot.com/         *
*      or mail the corrected version to me at              *
*      Mazziesaccount@gmail.com                            *
*                                                          *
*      I do not want to enforce any copyright for using    *
*      this piece unmodified, but I would be glad if I     *
*      heard of you - in case this was informative/usefull *
*      to you.                                             *
*                                                          *
*      Revision History:                                   *
*                                                          *
*      -v0.0.1 16.09.2008/Maz                              *
*                                                          */
/* ******************************************************** */


lotto.h:

#include <stdio.h>

#ifndef LOTTOKONE_H
#define LOTTOKONE_H

struct lottokone;

typedef struct lottotulos
{
int lottoNroMaara;
int jokeriNroMaara;
int *lottonumerot;
int *jokeri;
}lottotulos;

typedef enum ElottoType
{
ElottoType_Perus = 0,
ElottoType_Viking,
ElottoType_PerusJaJokeri,
ElottoType_VikingJaJokeri,
ElottoType_Max
}ElottoType;

struct lottokone *lotto_luo( ElottoType lotonTyyli);
typedef void (*tuhoF)(struct lottokone **lotto);

typedef void (*arvontaF)(struct lottokone *lotto);
typedef lottotulos (*tulosF)(struct lottokone *lotto);

typedef struct lottokone
{
ElottoType ltype;
arvontaF arvo;
tulosF haeArvonnanTulos;
tuhoF lotto_tuhoa;
}lottokone;

#endif


lottoTesti.c:


/* ******************************************************** */
/*                                                          *
*      Implementation of a lotto engine written in C        *
*      Main purpose is to demonstrate that C can be used as *
*      object oriented programming language.               *
*                                                          *
*      Written by  Maz (2009)                              *
*      http://maz-programmersdiary.blogspot.com/           *
*      http://c-ohjelmoijanajatuksia.blogspot.com/         *
*                                                          *
*      You're free to use this piece of code.              *
*      You can also modify it freely, but if you           *
*      improve this, you must write the improved code      *
*      in comments at:                                     *
*      http://maz-programmersdiary.blogspot.com/           *
*      or at:                                              *
*      http://c-ohjelmoijanajatuksia.blogspot.com/         *
*      or mail the corrected version to me at              *
*      Mazziesaccount@gmail.com                            *
*                                                          *
*      I do not want to enforce any copyright for using    *
*      this piece unmodified, but I would be glad if I     *
*      heard of you - in case this was informative/usefull *
*      to you.                                             *
*                                                          *
*      Revision History:                                   *
*                                                          *
*      -v0.0.1 16.09.2008/Maz                              *
*                                                          */
/* ******************************************************** */


#include "lotto.h"
#include <stdio.h>
int main(void)
{
int i;
lottokone *lotto;
lottotulos tulos;
lotto=lotto_luo(ElottoType_Perus);
lotto->arvo(lotto);
tulos=lotto->haeArvonnanTulos(lotto);
/*
Ollaksemme Wielä Enemmän OlioOtuksia, voisimme 
tunkea tulos structiin sekalaisen joukon funktioita, 
joilla arvotut numerot voisi esim. tulostaa
*/
for(i=0;i<tulos.lottoNroMaara;i++)
{
printf("nro %d = %u\n",i+1,tulos.lottonumerot[i]);
}
return 0;
}




lotto_sisainen.h


/* ******************************************************** */
/*                                                          *
*      Implementation of a lotto engine written in C        *
*      Main purpose is to demonstrate that C can be used as *
*      object oriented programming language.               *
*                                                          *
*      Written by  Maz (2009)                              *
*      http://maz-programmersdiary.blogspot.com/           *
*      http://c-ohjelmoijanajatuksia.blogspot.com/         *
*                                                          *
*      You're free to use this piece of code.              *
*      You can also modify it freely, but if you           *
*      improve this, you must write the improved code      *
*      in comments at:                                     *
*      http://maz-programmersdiary.blogspot.com/           *
*      or at:                                              *
*      http://c-ohjelmoijanajatuksia.blogspot.com/         *
*      or mail the corrected version to me at              *
*      Mazziesaccount@gmail.com                            *
*                                                          *
*      I do not want to enforce any copyright for using    *
*      this piece unmodified, but I would be glad if I     *
*      heard of you - in case this was informative/usefull *
*      to you.                                             *
*                                                          *
*      Revision History:                                   *
*                                                          *
*      -v0.0.1 16.09.2008/Maz                              *
*                                                          */
/* ******************************************************** */


#ifndef SISAINEN_LOTTO_H
#define SISAINEN_LOTTO_H

#include <stdio.h>
#include "lotto.h"
#include <stdlib.h>

#define LOTTO_NRO_MAARA 10
#define VIKINGLOTTO_NRO_MAARA 6
#define JOKERI_NRO_MAARA 7
#define VIKINGJOKERI_NRO_MAARA 7
#define LOTTO_MAX 45
#define VIKINGLOTTO_MAX 45

typedef struct SlottoPerus
{
lottokone virtlotto;
int jokerimukana; 
/* itse asiassa kaikille lottotyypeille 
voitaisiin käyttää samaa typedef structia, tai C++ 
tyyliin, esim jokerimukana muuttuja voitaisiin siirtää 
"base" luokkaan (eli lottokone structiin, tai muuhun 
yhteiseen (sisäiseen) structiin) 
*/
arvontaF arvo;
tulosF haeArvonnanTulos;
char tulosplaceholder[1];
}SlottoPerus;

typedef struct SlottoViking
{
lottokone virtlotto;
int jokerimukana;
arvontaF arvo;
tulosF haeArvonnanTulos;
char tulosplaceholder[1];

}SlottoViking;

typedef struct SperusNumerot
{
int lottoNumerot[LOTTO_NRO_MAARA];
}SperusNumerot;

typedef struct SvikingNumerot
{
int vikingNumerot[VIKINGLOTTO_NRO_MAARA];
}SvikingNumerot;

typedef struct SperusJokeriNumerot
{
int jokeriNumerot[JOKERI_NRO_MAARA];
}SperusJokeriNumerot;

typedef struct SvikingJokeriNumerot
{
int vikinJokeriNumerot[VIKINGJOKERI_NRO_MAARA];
}SvikingJokeriNumerot;


lottotulos vikingtulos(lottokone *siht_);
void vikingarvonta(lottokone *siht_);
void perusarvonta(lottokone *siht_);
lottotulos perustulos(lottokone *siht_);


#endif



lotto.c


/* ******************************************************** */
/*                                                          *
*      Implementation of a lotto engine written in C        *
*      Main purpose is to demonstrate that C can be used as *
*      object oriented programming language.               *
*                                                          *
*      Written by  Maz (2009)                              *
*      http://maz-programmersdiary.blogspot.com/           *
*      http://c-ohjelmoijanajatuksia.blogspot.com/         *
*                                                          *
*      You're free to use this piece of code.              *
*      You can also modify it freely, but if you           *
*      improve this, you must write the improved code      *
*      in comments at:                                     *
*      http://maz-programmersdiary.blogspot.com/           *
*      or at:                                              *
*      http://c-ohjelmoijanajatuksia.blogspot.com/         *
*      or mail the corrected version to me at              *
*      Mazziesaccount@gmail.com                            *
*                                                          *
*      I do not want to enforce any copyright for using    *
*      this piece unmodified, but I would be glad if I     *
*      heard of you - in case this was informative/usefull *
*      to you.                                             *
*                                                          *
*      Revision History:                                   *
*                                                          *
*      -v0.0.1 16.09.2008/Maz                              *
*                                                          */
/* ******************************************************** */


//#include "lotto.h"
#include "lotto_sisainen.h"

static lottotulos virtuaalitulos(lottokone *lotto);
static void virtuaaliarvonta(lottokone *_this);

static void lotto_tuhoa(lottokone **lotto)
{
free(*lotto);
lotto=NULL;
}
lottokone *lotto_luo(ElottoType lotonTyyli)
{
void *paluuarvo;
switch(lotonTyyli)
{
case ElottoType_Perus:
{
 SlottoPerus *peruslotto;
 peruslotto=malloc
 (
  sizeof(SlottoPerus)+sizeof(SperusNumerot)-1
 );
 paluuarvo=(void *)peruslotto;  if(peruslotto==NULL)
 {
  printf("lotto_alusta() : pannahinen, muisti loppu?");
  break;
 }
 peruslotto->virtlotto.ltype=lotonTyyli;
 peruslotto->virtlotto.lotto_tuhoa=&lotto_tuhoa;
 peruslotto->virtlotto.arvo=&virtuaaliarvonta;
 peruslotto->virtlotto.haeArvonnanTulos=&virtuaalitulos;
 peruslotto->jokerimukana=0; //tämä on kyllä huijausta, en jakasa leikkiä olioihmistä ja tehdä jokeri oliota, tahi eri oliota lotolle ja lotolle jokerin kera...
 peruslotto->arvo=&perusarvonta;
 peruslotto->haeArvonnanTulos=&perustulos;
 break;
}
case ElottoType_Viking:
{
 SlottoViking *vikinglotto;
 vikinglotto=malloc
 (
   sizeof(SlottoViking)+
   sizeof(SvikingNumerot)-1
 );
 paluuarvo=(void *)vikinglotto;
 if(vikinglotto==NULL)
 {
  printf("lotto_alusta() : pannahinen, muisti loppu?");
  break;
 }
 vikinglotto->virtlotto.ltype=lotonTyyli;
 vikinglotto->virtlotto.lotto_tuhoa=&lotto_tuhoa; 
 vikinglotto->virtlotto.arvo=&virtuaaliarvonta;
 vikinglotto->virtlotto.haeArvonnanTulos=&virtuaalitulos;
 vikinglotto->jokerimukana=0; 
/*
  tämä on kyllä huijausta, en jakasa leikkiä olioihmistä ja
  tehdä jokeri oliota, 
  tahi eri oliota lotolle ja lotolle jokerin kera...
*/
 vikinglotto->arvo=&vikingarvonta;
 vikinglotto->haeArvonnanTulos=&vikingtulos;
 break;
}

break;
case ElottoType_PerusJaJokeri:
{
 SlottoPerus *peruslotto;
 peruslotto=malloc
 (
   sizeof(SlottoPerus)+
   sizeof(SperusNumerot)+
   sizeof(SperusJokeriNumerot)-1
 );
 paluuarvo=(void *)peruslotto;
 if(peruslotto==NULL)
 {
  printf("lotto_alusta() : pannahinen, muisti loppu?");
  break;
 }
 peruslotto->virtlotto.ltype=lotonTyyli;
 peruslotto->virtlotto.arvo=&virtuaaliarvonta;
 peruslotto->virtlotto.lotto_tuhoa=&lotto_tuhoa;
 peruslotto->virtlotto.haeArvonnanTulos=&virtuaalitulos;
 peruslotto->jokerimukana=1; 
 //tämä oli myös huijausta
 peruslotto->arvo=&perusarvonta;
 peruslotto->haeArvonnanTulos=&perustulos;
 break;
}

break;
case ElottoType_VikingJaJokeri:
{
 SlottoViking *vikinglotto;
 vikinglotto=malloc
 (
   sizeof(SlottoViking)+
   sizeof(SvikingNumerot)+
   sizeof(SvikingJokeriNumerot)-1
 );
 paluuarvo=(void *)vikinglotto;
 if(vikinglotto==NULL)
 {
  printf("lotto_alusta() : pannahinen, muisti loppu?");
  break;
 }
 vikinglotto->virtlotto.ltype=lotonTyyli;
 vikinglotto->virtlotto.lotto_tuhoa=&lotto_tuhoa;
 vikinglotto->virtlotto.arvo=&virtuaaliarvonta;
 vikinglotto->virtlotto.haeArvonnanTulos=&virtuaalitulos;
 vikinglotto->jokerimukana=1;
 vikinglotto->arvo=&vikingarvonta;
 vikinglotto->haeArvonnanTulos=&vikingtulos;
 break;
}
break;
default:
 printf
 (
  "lotto_alusta() : Pannahinen, annoit olemattoman lottotyypin!\n"
  );
 paluuarvo=NULL;
break;
}
return (lottokone *)paluuarvo;

}

static void virtuaaliarvonta(lottokone *_this)
{
if(*(unsigned int*)_this<ElottoType_Max)
{
/*
 Jos tekisin tätä helpolla ja yksinkertaisella C -
 tyylillä, tässä olisi hyppytaulu eri 
 lottoarvontafunktioihin, indexoituna 
 ElottoType:llä

 koska tämän on kuitenkin tarkoitus matkia C++:n 
 virtuaaliluokkaa, kutsutaan täältä "aliluokan 
 sisällä olevaa" funktiota. Nyt siis tämä if-else 
 runko olisi voitu korvata seuraavalla switch
 rakenteella, mutta if-else rakenne on täällä, 
 jotta hyppytaulun käyttöidea näkyisi. Ts. tässä 
 voisi olla:
 arvontaF arvontafunktiot[ElottoType_Max];
 arvontafunktiot[ElottoType_Perus]=
 &perusarvontafunktio;
 arvontafunktiot[ElottoType_Viking]=
 &viikinkiarvontafunktio;
 arvontafunktiot[ElottoType_PerusJaJokeri]=
 &perusjokeriarvontafunktio;
 arvontafunktiot[ElottoType_VikingJaJokeri]=
 &viikinkijokeriarvontafunktio;
 *arvontafunktiot[*(unsigned int*)_this](_this);
*/
switch(*(unsigned int*)_this<ElottoType_Max)
{
 case ElottoType_Perus:
  return ((SlottoPerus*)_this)->arvo(_this);
 break;
 case ElottoType_Viking:
  return ((SlottoViking*)_this)->arvo(_this);
 break;
 case ElottoType_PerusJaJokeri:
  return ((SlottoPerus*)_this)->arvo(_this); 
 break;
 case ElottoType_VikingJaJokeri:
  return ((SlottoViking*)_this)->arvo(_this); 
 break;
 default:
  printf("Mahdoton Tapahtui!!! %s:%d\n",__FILE__,__LINE__);
  fflush(stdout);
  exit(-1);
 break;
}
}
else
{
printf
(
 "lottoarvonta : pannahinen, joku meni poskelleen, lotto olio viallinen!"
);
fflush(stdout);
exit(-1);
}
}
static lottotulos virtuaalitulos(lottokone *_this)
{
 switch(*(unsigned int*)_this<ElottoType_Max)
 {
 case ElottoType_Perus:
  return ((SlottoPerus*)_this)->haeArvonnanTulos(_this);
 break;
 case ElottoType_Viking:
  return ((SlottoViking*)_this)->haeArvonnanTulos(_this);
 break;
case ElottoType_PerusJaJokeri:
 return ((SlottoPerus*)_this)->haeArvonnanTulos(_this); 
break;
case ElottoType_VikingJaJokeri:
 return ((SlottoViking*)_this)->haeArvonnanTulos(_this); 
break;
default:
 printf
 (
  "lottoHaeTulos : pannahinen, joku meni poskelleen, lotto olio viallinen!"
 );
 fflush(stdout);
 exit(-1);
break;
}
}



peruslotto.c



/* ******************************************************** */
/*                                                          *
*      Implementation of a lotto engine written in C        *
*      Main purpose is to demonstrate that C can be used as *
*      object oriented programming language.               *
*                                                          *
*      Written by  Maz (2009)                              *
*      http://maz-programmersdiary.blogspot.com/           *
*      http://c-ohjelmoijanajatuksia.blogspot.com/         *
*                                                          *
*      You're free to use this piece of code.              *
*      You can also modify it freely, but if you           *
*      improve this, you must write the improved code      *
*      in comments at:                                     *
*      http://maz-programmersdiary.blogspot.com/           *
*      or at:                                              *
*      http://c-ohjelmoijanajatuksia.blogspot.com/         *
*      or mail the corrected version to me at              *
*      Mazziesaccount@gmail.com                            *
*                                                          *
*      I do not want to enforce any copyright for using    *
*      this piece unmodified, but I would be glad if I     *
*      heard of you - in case this was informative/usefull *
*      to you.                                             *
*                                                          *
*      Revision History:                                   *
*                                                          *
*      -v0.0.1 16.09.2008/Maz                              *
*                                                          */
/* ******************************************************** */


#include <stdlib.h>
#include <time.h>
#include <string.h>
#include "lotto_sisainen.h"

lottotulos perustulos(lottokone *siht_)
{
SlottoPerus *_this = (SlottoPerus *)siht_;
lottotulos tulos;
memset(&tulos,0,sizeof(lottotulos));
if
(
 *(unsigned int*)_this!=ElottoType_Perus &&
 *(unsigned int*)_this!=ElottoType_PerusJaJokeri 
)
{
 printf("perustuloshae : lottokone rikki, soittakaa Wirallisille Walvojille!!");
 fflush(stdout);
 exit(-1);
}
if(_this->jokerimukana)
{
 tulos.jokeriNroMaara=JOKERI_NRO_MAARA;
 tulos.jokeri=
 &(((int *)_this->tulosplaceholder)[LOTTO_NRO_MAARA]);
}
tulos.lottoNroMaara=LOTTO_NRO_MAARA;
tulos.lottonumerot=(int *)(_this->tulosplaceholder);
return tulos;
}
void perusarvonta(lottokone *siht_)
{
SlottoPerus *_this = (SlottoPerus *)siht_;

int i, ok;

srand(time(NULL));
if
(
 *(unsigned int*)_this!=
 ElottoType_Perus &&
 *(unsigned int*)_this!=
 ElottoType_PerusJaJokeri 
)
{
 printf
 (
  "perusarvonta : lottokone rikki, soittakaa Wirallisille Walvojille!!"
 );
 fflush(stdout);
 exit(-1);
}
for(i=0;i<LOTTO_NRO_MAARA;i++)
{
ok=0;
while(!ok)
{
 int j;
 ok=1;
 ((int *)_this->tulosplaceholder)[i]=
 (rand()%LOTTO_MAX+1);
 //varmista että arvottu numero on uniikki
 for(j=0;j<i;j++)
 {
  if
  (
    ((int *)_this->tulosplaceholder)[i] == 
    ((int *)_this->tulosplaceholder)[j]
  )
  {
   //sama numero arvottiin kahteen kertaan => hylkää!
   ok=0;
   //koska tupla-arvo löytyi jo, ei kannata jatkaa.
   break;
  }
 }
}
}
if(_this->jokerimukana)
{
for(i=0;i<JOKERI_NRO_MAARA;i++)
{
 ok=0;
 while(!ok)
 {
  int j;
  ok=1;
  ((int *)_this->tulosplaceholder)[LOTTO_NRO_MAARA+i]=
  (rand()%LOTTO_MAX+1);
  //varmista että arvottu numero on uniikki
  for(j=0;j<i;j++)
  {
   if(
   ((int *)_this->tulosplaceholder)[LOTTO_NRO_MAARA+i]==
   ((int *)_this->tulosplaceholder)[LOTTO_NRO_MAARA+j]
   )
   {
    //sama numero arvottiin kahteen kertaan => hylkää!
    ok=0;
    //koska tupla-arvo löytyi jo, ei kannata jatkaa.
    break;
   }
  }
 }
}
}
}





vikinglotto.c



/* ******************************************************** */
/*                                                          *
*      Implementation of a lotto engine written in C        *
*      Main purpose is to demonstrate that C can be used as *
*      object oriented programming language.               *
*                                                          *
*      Written by  Maz (2009)                              *
*      http://maz-programmersdiary.blogspot.com/           *
*      http://c-ohjelmoijanajatuksia.blogspot.com/         *
*                                                          *
*      You're free to use this piece of code.              *
*      You can also modify it freely, but if you           *
*      improve this, you must write the improved code      *
*      in comments at:                                     *
*      http://maz-programmersdiary.blogspot.com/           *
*      or at:                                              *
*      http://c-ohjelmoijanajatuksia.blogspot.com/         *
*      or mail the corrected version to me at              *
*      Mazziesaccount@gmail.com                            *
*                                                          *
*      I do not want to enforce any copyright for using    *
*      this piece unmodified, but I would be glad if I     *
*      heard of you - in case this was informative/usefull *
*      to you.                                             *
*                                                          *
*      Revision History:                                   *
*                                                          *
*      -v0.0.1 16.09.2008/Maz                              *
*                                                          */
/* ******************************************************** */


#include <stdlib.h>
#include <time.h>
#include <string.h>

#include "lotto_sisainen.h"

lottotulos vikingtulos(lottokone *siht_)
{
SlottoViking *_this = (SlottoViking *)siht_;
lottotulos tulos;
memset(&tulos,0,sizeof(lottotulos));
if
(
 *(unsigned int*)_this!=
 ElottoType_Perus &&*(unsigned int*)_this!=
 ElottoType_PerusJaJokeri 
 )
{
printf
(
 "perustuloshae : lottokone rikki, soittakaa Wirallisille Walvojille!!"
 );
 fflush(stdout);
 exit(-1);
}
if(_this->jokerimukana)
{
tulos.jokeriNroMaara=JOKERI_NRO_MAARA;
tulos.jokeri=
&(((int *)_this->tulosplaceholder)[VIKINGLOTTO_NRO_MAARA]);
}
tulos.lottoNroMaara=VIKINGLOTTO_NRO_MAARA;
tulos.lottonumerot=(int *)(_this->tulosplaceholder);
return tulos;
}
void vikingarvonta(lottokone *siht_)
{
SlottoViking *_this = (SlottoViking *)siht_;

int i, ok;

srand(time(NULL));
if
(
 *(unsigned int*)_this!=
 ElottoType_Viking &&*(unsigned int*)_this!=
 ElottoType_VikingJaJokeri 
)
{
printf
(
 "perusarvonta : lottokone rikki, soittakaa Wirallisille Walvojille!!"
);
 fflush(stdout);
 exit(-1);
}
for(i=0;i<VIKINGLOTTO_NRO_MAARA;i++)
{
ok=0;
while(!ok)
{
 int j;
 ok=1;
 ((int *)_this->tulosplaceholder)[i]=
 (rand()%LOTTO_MAX+1);
 //varmista että arvottu numero on uniikki
 for(j=0;j<i;j++)
 {
  if
  (
   ((int *)_this->tulosplaceholder)[i]== 
   ((int *)_this->tulosplaceholder)[j]
  )
  {
   //sama numero arvottiin kahteen kertaan => hylkää!
   ok=0;
   //koska tupla-arvo löytyi jo, ei kannata jatkaa.
   break;
  }
 }
}
}
if(_this->jokerimukana)
{
for(i=0;i<VIKINGJOKERI_NRO_MAARA;i++)
{
 ok=0;
 while(!ok)
 {
  int j;
  ok=1;
  ((int *)_this->tulosplaceholder)[VIKINGLOTTO_NRO_MAARA+i]=
  (rand()%LOTTO_MAX+1);
  //varmista että arvottu numero on uniikki
  for(j=0;j<i;j++)
  {
   if
   (
    ((int *)_this->tulosplaceholder)[VIKINGLOTTO_NRO_MAARA+i]==
    ((int *)_this->tulosplaceholder)[VIKINGLOTTO_NRO_MAARA+j]
   )
   {
    //sama numero arvottiin kahteen kertaan => hylkää!
    ok=0;
    //koska tupla-arvo löytyi jo, ei kannata jatkaa.
    break;
   }
  }
 }
}
}
}

Kääntäminen gcc:llä onnistuu käskyllä:

gcc -Wall -o lottoEsimerkki lottoTesti.c lotto.c peruslotto.c vikinglotto.c

Ja vielä teille jotka kahlasitte tänne asti...

Eli, loppusanat:

C++ on hyvä kieli, ja olio-ohjelmointi on tuonut joitain hienoja piirteitä tullessaan. Mutta Olio-Ohjelmointi ei automaattisesti tarkoita hyvää asiaa. Monet olio-ohjelmoijat ovat uponneet liian syvälle oliokuoppaansa, eivätkä näe enää metsää puilta. Liian pitkälle menevä perintä lienee yksi kauheimmista asioista mitä tiedän. Olen joskus joutunut porautumaan oliopohjalta tehtyyn koodiin, ja tekemään sen päälle jotain.. Usein huomasin vasta päiviä puuhasteltuani, että sama asia jota tein kaikkien periytettyjen oliokerrosten päälle, olijo (<=kirjoitusvirhe tarkoituksellinen) toteutettu jossain alempien kerrosten syövereissä. Ja kaikenkaikkiaan, nykyään tuntuu, että Olio-ohjelmointi nähdään liian usein itse tarkoituksena, ei suinkaan työkaluna joksi se on tarkoitettu. On tilanteita joissa oliokielet ovat hyviä, mutta on myös tilanteita joissa proseduraalisella kielellä saavutetaan tavoite paljon pienemmällä koodimäärällä, yksinkertaisemmin, ylläpidettävämmin ja ymmärrettävämmin. Siis muistakaa tytöt ja pojat, (niin, sinäkin Vesa): Olio-ohjelmoijien ja ohjelmoinnin päätarkoitus ei oikeasti ole vain kikkailla ja keksiä entistä hienompia olio-ismejä.

Ja viimeinen kommentti. Koodiesimerkit tuppaavat menemään rikki tässä html wysiwyg maailmassa - olen pahoillani. Koetan saada lottokone-esimerkin pakattua zippiin, ja jonnekkin palvelimelle, mikäli joku haluaa oikeasti nähdä sen / koettaa sitä :)

Atomiset operaatiot.

2009-04-03T22:44:00.004+03:00

HepHep!

Sorsat saatavilla reposta
http://xp-dev.com/svn/MazBotV4/branches/oldprojects/atomic_example.tar.gz

Nyt mukaan pakettiin livautettu myös esimerkkisorsa, jossa käytetään ++ - operaatiota tavalliseen muuttujaan ja atomista operaatiota. Näitä muuttujia käsitellään esimerkissä 10 - säikeestä, ja ainakin minun koeajoissa nähtiin miten normaalin globaalin kasvattaminen ++-operaatiolla, ei ollut turvallinen monisäikeisessä ympäristössä.

Säikeistä (aiheen pohjustus)

Tunnen suurta syyllisyyttä siitä, että esittelin blogissani säikeet eli threadit. Ne ovat kuin Star Warsin "voiman", paha, "pimeä puoli". Niiden käyttöön on helppo lipsahtaa. Ne houkuttelevat siinä aivan käden ulottuvilla, tarjoten nerokkaalta tuntuvia ratkaisuja - ja kun kerran kokeilet, jäät helposti koukkuun.

No joo. Hieman karrikoitua, sitäpaitsi tälläkertaa en aikonut kirjoittaa säikeistä varsinaisesti, mutta kun kerran atomiset operaatiot liittyvät kiinteästi säikeisiin, kirjoitetaan nopeasti ylös muutamia asioita joita on hyvä pitää mielessä...

Säikeet siis tarjoavat tavan suorittaa näennäisen yhtäaikaisesti useampaa kohtaa ohjelmakoodissa. Toisinaan tämä auttaa yksinkertaistamaan asioita merkittävästi. Yhden säikeen voi esim. luoda odottamaan käyttäjältä syötettä, toisen säikeen suorittaessa taustalla jotain tarpeellista tehtävää. Miksi sitten avasin tekstini syyttämällä säikeitä maailman suurista onnettomuuksista?

Vaikka säikeet tuntuvat helpolta tavalta hanskata blokkaavat I/O kutsut ja tehdä monia yhdenaikaisia toimenpiteitä, on säikeissä omat nurjat puolensa.

Synkronointi.
Joskus asioita vaan tulee tehdä tietyssä järjestyksessä. Maitoa ei voi kaataa lasiin, ennen kuin purkki on avattu. Uunin peltejä ei voi laittaa kiinni, ennen kuin tuli on sammunut. Ja ehkä tyypillisimmillään ohjelmoinnissa, palvelua ei voida käyttää, ennen kuin se on alustettu (palautuu yleensä siihen seikkaan, että muistiin ei voi kirjoittaa ennen kuin se on varattu) jne. Käytettäessä useampia säikeitä, eri säikeiden suoritusjärjestys uskotaan schedulerin haltuun. Ts. suoritusjärjestys on jokseenkin epämääräinen, ja voi vaihdella ajokerrasta toiseen. Tyypillisesti tässä käytetään apuna semaforeja, mutexeja ja conditional variableja.

Yhteisten resurssien suojaus.
Eli mikäli useampi kuin yksi säie päivittää jotain yhteistä resurssia (esim, globaalia muuttujaa), voi tulla ongelmia jolloin säikeet ovat päivittämässä samaa paikkaa yhtäaikaa. Perusesimerkkinä globaalin muuttujan lisäys yhdellä - mutta aloitankin varsinaisen "atomic operation" matskun sillä, jahka sinne asti pääsen.

Ja viimeisenä, mutta ei varmastikkaan mitenkään vähäpätöisenä tulee

ohjelman vikojen korjaus ja ylläpito.
Totuushan on, että virheetöntä koodia ei ole, käytettiin säikeitä tai ei. Mutta se mikä monisäikeisessä ohjelmassa saa hiukset nousemaan pystyyn, ja naaman kalpenemaan, on "viuhupointterin" löytämisen hankaluus. Verrattaessa useassa säikeessä ajettavaa ohjelmaa, esim. useassa prosessissa ajettavaan, huomataan yleensä ensimmäisenä se, että saman prosessin kaikilla säikeillä on pääsy kaikkien säikeiden osoiteavaruuteen. Prosesseillahan tuo osoiteavaruus on suojattu. Eli sen lisäksi että globaalit muuttujat on käytössä kaikissa säikeissä, voidaan osoittimilla sohia sujuvasti toisten säikeiden pinoihin (ja luonnollisesti sinne yhteiseen kekoon). Datan jakaminen on siis helppoa, mutta myös koodiin lipsahtanut viuhupointteri saattaa sujuvasti muuttaa dataa toisen threadin tontilta, saaden aikaan merkillisiä vikoja jossain ihan muualla kuin siellä missä viuhupointteri on. Hankalampaa kuin prosessien kanssa sanon minä, sillä mikäli viuhupointteri osoittaisi toisen prosessin osoiteavaruuteen, saataisiin välittömästi generoitua SIGSEGV eli segmentation faultti (tai access violation wintoosalla).

No niin... Siinäpä sitä säieasiaa jo tulikin, kirjoitukseen jonka ei ollut tarkoitus käsitellä säikeitä...

Miksi atomisuus??

Aiemmin mainitsin ongelman, jossa kaksi säiettä yrittää yhtä aikaa kasvattaa globaalia muuttujaa yhdellä. Siis kumpikin säie ajaa koodia

globaali++;

Mietitäänpä hetki. Mitä globaali++; oikeastaan tekee? Se:

1. lukee globaali muuttujan arvon muistista.
2. kasvattaa arvoa yhdellä.
3. kirjoittaa tuloksen takaisin globaali muuttujaan.

Jos kaksi säiettä nyt tekee tätä yhtäaikaa, voi lopputulos olla seuraava:

Säie1 aloittaa. Se:

lukee globaalin arvon
laskee globaali+1

ja nyt scheduleri päättääkin antaa säikeelle 2 vuoron edetä, ja pysäyttää säikeen 1.

säie 2 lukee globaali muuttujan arvon (joka siis on vielä sama minkä säie 1 luki)
säie 2 laskee globaali+1
ja kirjoittaa tuloksen muuttujaan globaali.

tovin päästä scheduleri antaa säikeelle 1 luvan jatkaa, ja se kirjoittaa edellä tekemänsä laskutoimituksen summan muuttujaan globaali, onnellisen tietämättömänä siitä, että säie 2 on kasvattanut globaalia välillä. Lopputulos siis uhmaa koulumatematiikkaa, ja jos oletetaan globaalin olleen alussa voikka 534, laskutoimituksen päättyessä, 534+1+1 = 535. Ja kun lisätään soppaan se, että tämä voi todellakin tapahtua vasta kun globaalia on päivitetty 534 kertaa onnistuneesti (mahdollisesti tuntien toiminnan jälkeen), ja se, että ohjelma ei välttämättä kaadu virheeseen.. Voihan olla että joka viidessadas pankkiautomaatilla laskuja maksava asiakas aikaansaa yhden sentin virheen pankin kirjanpidossa... ... ... ... Koetan vain sanoa, että vika on usein äärimmäisen vaikeaa paikantaa.

Edellinen esimerkki oli vieläpä äärimmäisen yksinkertainen. Todelliset ongelmat ovat usein paljon monimutkaisempia operaatioita, jota ei suotaisi katkaistavan.

Tässävaiheessa sivistyneempi teistä kahdesta lukijastani (se et edelleenkään ole sinä Vesa) lienee huomannut yhtäläisyyden kuvaamani ongelman ja sanan atominen kanssa. Atominen (atomic) tarkoittaa jakamatonta. Ja atominen operaatio siis operaatiota, jota ei voi jakaa... Eli, jos lue, lisää, kirjoita olisikin käsky, joka tapahtuisi "jakamattomasti" siten, että välissä ei voida tehdä muuta, olisimme autettuja.

Atomisuuden vaihtoehdot

Lääkettä vaivaan sanoi entinen mies kun loippaa otti. Ongelmaan onkin tarjolla useita ratkaisuja.

Keskeytysten disablointi.
Koodarinplanttu voi vetää scheduleria nenästä disabloimalla keskeytykset, jolloin scheduleri ei pääse scheduloimaan muita säikeitä / prosesseja ajoon. Kuulostaa hyvältä. Ikävä kyllä, keskeytysten disabloinnilla on sivuvaikutuksensa. Masiina nimittäin käyttää keskeytyksiä paljon muuhunkin, muunmuassa kommunikointiin raudan ja käyttöjärjestelmän välillä. Lisäksi monet operaatiot ovat riippuvaisia prosesseista, jotka ovat taustalla ajossa. Lisäksi voi koneessa pyöriä prosesseja, joiden on päästävä ajoon... Siis keskeytysten disabloinnin tulisi aina olla äärimmäisen lyhytkestoista, ja tällä välin ohjelmalla on rajoitettu määrä operaatioita käytettävissään... Ja... Vesakin varmaan tietää, että nykyään useissa koneissa on enemmän kuin yksi prosessori. Siis vaikka toisella prosessorilla scheduleri lukittaisiin, toisella prosessorilla voi ajoon päästä jotain, joka sotkee aristoteleen ympyrät...

Mutexit ja semaforit.
Niistä olenkin kertonut jo aiemmassa blogitekstissäni. Ja ne ovat nerokkaita viritelmiä - jotka useimmiten perustuvat atomisiin operaatioihin. Mutta mitä pidempään mutexi on yhdellä säikeellä lukossa, sitä kauemmin muut säikeet joutuvat odottelemaan. Puhumattakaan vaaroista kuten deadlockit ja starvation.

Atomiset operaatiot (Joo, nyt pääsin ihan oikeasti asiaan)

Onneksemme (oh, ylistäkäämme insinöörien nerokkuutta [minähän en muuten siihen sakkiin kuulu, toisin kuin Vesa]) suurin osa prosessoreista tukee muutamia ihan perustavanlaatuisia atomisia käskyjä, jotka voidaan asm:lla koodailla C-koodin joukkoon. (Eli useisiin prosessoreihin on rakennettu ihan "rautatuki" takaamaan tiettyjen yksinkertaisten operaatioiden keskeyttämättömyys). Ja kun muutama tällainen peruspalikka on käytössä, pystyy koodari kikkailemaan lisää käskyjä, jotka ulospäin näyttävät atomisilta.

Kaikki lhtee yleensä liikkeelle 32 bittisen (int) luvun kirjoittamisesta / lukemisesta muistiin/muistista. Onko siis luku / kirjoitus atominen? Savolainen osaisi varmasti sanoa tähän jotain näppärää ja tulkitsematonta, mutta minä sensijaan sanon, että: "Se vähän riippuu siitä, mistä se roikkuu."

Ok. Helpotetaan hiukan. Nykykoneilla joissa väylät ovat yleensä vähintään 32 bittisiä, luku ja kirjoitus on yleensä atomisia. Vanhemmilla/erikoisemmilla koneilla ei välttämättä. Pitempien lukujen kohdalla taas 32 bittiset koneet usein lukevat/kirjoitttavat kahdessa osassa, ja tällaisen luvun / kirjoituksen sekaan sössiminen usealla säikeellä, saa aikaan lukuja joissa on puolet yhtä, ja toinen puoli toista, eli jotka siis ovat ihan mitä sattuu. Ja 32 bittisiäkin lukuja jäsiteltäessä on hyvä muistaa, että kääntäjä saattaa optimoida koodia siten, että lukuja käytetäänkin rekistereistä tai cachesta... Tällaisten sekaannuksien välttämiseksi, atomisiin operaatioihin tarkoitetut muuttujat on hyvä höystää "volatile" avainsanalla, joka kertoo kääntäjälle, että olisi hyvin suotavaa, mikäli tämä luku pidettäisiin aina muistissa, eikä sitä optimoitaisi rekistereihin jne.

No niin Vesa, lopetappa se volatilen viljely, ja ota kääntäjän manuska karvaiseen kouraasi.

Volatile (ja register) sanoja kun käytetään oikeastaan vaan vihjeenä kääntäjälle. Osa kääntäjistä hoitaa homman kotiin, osa antaa palttua koodarin toiveille, ja osa jotain siltä väliltä. Kannattaa siis katsoa, ennen kuin katuu.

Compare and Swap

Oikeastaan tässä alkaa olla jo tarinaa joka vinkkaa oikeaan suuntaan, mutta paukutetaan vielä pari juttua. En nimittäin malta olla esittelemättä parasta kaveriani, atomista "CMS" eli "CompareAndSwap" käskyä. Joo Vesa, komealtahan se nimi kuulostaa, mutta se ei ollut syy miksi haluan esitellä juuri compare and swapin. Syy on se, että kun olet toteuttanut atomisen compare and swap käskyn, voit rakentaa sen avulla kokonaisen ison liudan muita atomisia käskyjä.

Compare and swap siis tekee seuraavan tempun. Se ottaa käyttäjältä parametreinaan muistiosoitteen, ja kaksi lukua. Se tarkistaa muistiosoitteen sisällön, vertaa sitä annettuun lukuun, ja mikäli sisältö on sama kuin annettu luku, se vaihtaa muistiosoitteen sisällön toiseen annettuun lukuun. Lopuksi se palauttaa arvon, joka kertoo tehtiinkö swap vai ei. Ja kaiken tämän vieläpä atomisesti. Paluuarvona on tyypillisesti joko true/false tai arvo joka muistipaikasta luettin. (Siis, jos muistipaikan sisältö oli sama kuin annettu vertailumuuttuja => uusi arvo kirjoitettiin => vertailumuuttujaa vastaava arvo palautetaan. Muuten palautettava arvo on eri kuin vertailuarvo).

Todennäköisesti lähes kaikki nykyiset prosessorit tukevat atomista CMS käskyä. Ainakin x86, AMD ja ne PPC prosessorit joihin olen törmännyt.

Uusien atomisten käskyjen rakentelu

No niin. Mainitsinkin jo, että CMS käskyn avulla voidaan toteutta useita hienoja atomisia operaatioita. Vesakin voi lopettaa nauramisen, se ei ollut vitsi. Atomisuus on siis käsite, joka toteuttaa seuraavat ehdot.

Jokin sarja operaatioita voidaan suorittaa siten, että ympäröivä maailma ei tiedä muutoksista joita se aiheuttaa ennen kuin se on kokonaisuudessaan päättynyt.
Ja jos jossakin operaation vaiheessa sössitään, koko operaatio epäonnistuu jälkiä jättämättä.

CMS:ää hyödyntäen voidaan nyt seuraavalla kaavalla toteutta iso joukko erilaisia:
"vertaa/manipuloi muistipaikassa olevaa dataa, ja kirjoita tulos takaisin muistiin"
operaatioita, jotka ovat ulospäin atomisia.

1. lue muistipaikan alkuperäinen arvo, ja talleta se väliaikaiseen muuttujaan.
2. vertaile / manipuloi dataa (toisessa väliaikaisessa muuttujassa)
3. Tee compareAndSwap, josa vertaat muistipaikassa tällähetkellä olevaa arvoa arvoon, joka siellä oli atomista funktiotasi kutsuttaessa. Laita swapattawaksi arvoksi manipulointisi tulos.
Toista loopissa kunnes swap onnistuu.

Eli, mikäli jokin muu säie pääsi muuttamaán muistipaikassa olevaa arvoa manipuloinnin/vertailun aikana, compare and swap funktiossa alkuperäinen, talletettu arvo ja manipuloinnin jälkeinen arvo eivät täsmää (operaatio ei ollut atominen) => swap ei onnistu. => uusi yritys.

Jos taas swap onnistuu, se tarkoitta, että kukaan ei kesken operaation käpistellyt muistipaikan sisältämää dataa, ja operaatio oli siis atominen.

Ja tässä vielä loppuhöysteenä tuo paljon hypettämäni compare and swap, ix86 prosessorille. (muistakaa, että intti jonka osoite funktiolle annetaan TÄYTYY olle volatile).

int __INLINE__ atominenCAS( int *ptr, int cmp, int new)
{
unsigned char ret;

__asm__ __volatile__ (
" lock\n"
" cmpxchgl %2,%1\n"
" sete %0\n"
: "=q" (ret), "=m" (*ptr)
: "r" (new), "m" (*ptr), "a" (cmp)
: "memory");

return ret;

}

Gdb watch pointit - pysähdy kun muistipaikassa oleva data muuttuu

2009-03-23T19:05:00.003+02:00

Gdb watchpointit - Stoppaa suoritus kun data muuttuu

Oikeastaan kirjoitin tämän tekstin alunperin tuohon aiempaan blogitekstiini (debuggauksesta ylensä), mutta koska se paisui kuin pullataikina, päätin laittaa tästä ihan oman osion.

Usein ohjelmissa on bugeja, joissa kirjoitetaan yli allokoidun tilan siten, että kirjoitus menee kerta toisensa jälkeen samaan paikkaan. (Esim, ylikirjoitettaessa staattisesti varattu taulukko). Mikäli sattuu niin ikävästi, että ylikirjoitettu muisti on varattu ohjelman käyttöön, voi olla, ettei käyttöjärjestelmä huomaa mitään virhettä, vaan ohjelma kyykkää myöhemmin mitä kummallisimpiin vikoihin. Tosi jänniä ilmiöitä saa aikaiseksi muunmuassa ylikirjoiottamalla jonkin tallennetun callbackfunktion osoittimen -> prosessorille annetaan suoritettavaksi mitä erikoisempia käskyjä :) Tällaisten "viuhupointtereiden" jäljittäminen voi olla todella työlästä.

Tällaisissa tapauksissa usein toivoisi, että muistiosoitteen voisi merkitä "seurattavaksi", eli jonkin vahtimaan osoitetta ja pysäyttämään suorituksen osoitteen päivittyessä. Näin saisi viuhupointterin käyttäjän kiinni itse teosta.

gdb antaa tähän valmiudet watchpointtien avulla. Tämä kuitenkin vaatii pari riviä lisäselvitystä.

Watchpoint on siis periaatteeltaan samanlainen kuin breakpoint, mutta nyt suoritus pysäytetään tietyn muuttujan (tai muistipaikan) arvoa luettaessa/kirjoitettaessa.

Gdb:ssä on tuki kahdenlaisille watchpointeille, "rauta" ja "softa" watchpointeille. Näissä kuitenkin on muutamia eroja:

Rautawatchpointit hyödyntävät prosessoriin tehtyä watchpoint tukea (johon en tarkemmin nyt mene). Kuitenkaan kaikissa prosessoreissa ei ole tukea tälle, tai gdb ei pysty kaikkien prosessorien tarjoamaa tukea hyödyntämään. Perus x86, ppc, ym prosessorien kanssa tämä tuki tulisi kuitenkin olla saatavilla.

Defaulttina rautawatchpointit on käytössä, mikäli ne on tuettuina. Tähän on pari syytä. Ensinnäkin, rautawatchpointit ovat nopeita. Niiden käyttö ei vaadi ylimääräistä prosessointiaikaa, sillä varsinainen työ tehdään jo rautatasolla. Lisäksi rautawatchpointit mahdollistavat ohjelman pysäytyksen "vahdittavaksi" määritettävää muuttujaa/muistiosoitetta luettaessa.

Softawtchpointit tätä lukemisen havaitsemista ei voida toteuttaa, ilman että jokainen käsky tutkittaisiin debuggerin toimesta, ja lukupyyntö tutkittaisiin. Tämä hidastaisi ohjelman suoritusta toivottoman paljon. Jo pelkkä muistipaikkojen kirjoituksen tutkiminen hidastaa ohjelman ajoa melkoisesti (Ts. softawatchpoittien käyttö hidastaa ohjelmaa merkittävästi jo nyt).

Vielä yksi ero softa ja rautawatchpointtien välillä tulee esiin monisäikeisiä ohjelmia debugattaessa. Softawatchpointti pystyy havaitsemaan kirjoituksen vain sen säikeen kontextista, jossa watchpointti asetettiin. Rautawatchpointti taas pystyy havaitsemaan luvut ja kirjoitukset säikeestä riippumatta, tosin rautawatchpointin luonnissa voidaan täsmentää minkä säikeen kontekstissa tulevista luvuista/kirjoituksista ollaan kiinnostuneita.

Pieni tarkennus on kuitenkin vielä paikallaan. Mikäli käytät muuttujan nimeä watchpointtia asetettaessa, watchpoint pysyy validina vain niin kauan, kun ohjelman suoritus pysyy siinä (funktion/tiedoston)kontekstissa, jossa muuttuja on näkyvillä. Jos haluat tutkia esim. jotain keosta varattua paikallista muuttujaa läpi koko ohjelman ajon, tulee sinun asettaa watchpointti muistialueen osoitteen, ei muuttujan nimen perusteella.

Ja nyt watchpointin syntaksiin:
Watchpoint muuttujan int foo sisällölle nimen ja osoitteen perusteella:

watch foo [threadinnumero mikäli rautawatchpointti]
watch (int)0xB00BBABE [threadinnumero mikäli rautawatchpointti]

Eli jälkimmäisessä siis oletetaan, että muuttuja foo on talletettu osoitteeseen 0xB00BBABE. Oikean osoitteen saat selville käskyllä

print &foo

Huomaa siis, että mikäli haluat ohjelman suorituksen pysähtyvän kun johonkin muistiosoitteeseen kirjoitetaan jotain, tulee sinun suorittaa oikeanlainen castaus, jotta gdb tietää minkäkokoista muistikönttiä annetusta osoitteesta eteenpäin halutaan tarkkailla. Laitetaanpä viekä selvennykseksi toinen esimerkki. Olkoon osoitteessa 0x00BADDAD nyt taulukko long long int *foo[5], eli taulukollinen osoittimia jotka osoittavat long long int tyyppiseen dataan.

Mikäli haluaisimme seurata sitä arvoa, johon taulukon kolmas osoitin osoittaa, komentaisimme:

watch *((long long int *)0x00BADDAD+2) [threadinnumero]

Lisaa gdb:sta

C:tä C++ tyyliin.

2009-03-21T22:59:00.003+02:00

Hi deee Ho!

Jaa-a. Tälläkertaa kirjoitan aiheesta, josta en ole koskaan aiemmin kirjoittanut. Enkä lukenut. Aiheesta, josta minulla on varsin rajalliset kokemukset. Aiheesta jota on hyvin vaikeaa rajata, aiheesta johon en voi sanoa "Näin se on. Tämä on oikein. Tämä taas väärin". Myönnetään, kysymyksenne "Kannattaako sellaisesta aiheesta kirjoittaa?" on aiheellinen. Mutta vastausta kysymykseenne etta saa muuten, kuin lukemalla tämän kirjoituksen - minä en voi sitä kertoa, sillä en itsekään sitä tiedä.

Viime aikoina olen useammassa kuin yhdessä C:llä koodaamassani komponentissa käyttänyt hieman tavallisuudesta poikkeavaa lähestymistapaa. Oikeastaan tämä tapa saattaa olla tutumpi C++ kuin C koodareille. Ja tämä tapa (en tiedä onko se yleisesti käytetty/tunnettu, enkä tiedä onko sillä nimeä) sanotaan sitä vaikka otus C:eeksi, minun on nyt tarkoitus esitellä.

.
.
.

Miettivä hiljaisuus. En tiedä miten etenisin. Taidan heittää tähän väliin esimerkin.

Viimeisin suuri koodaamani kokonaisuus on testisofta useille eri ajastimille. Enkä nyt tarkoita mitään rannekelloja, vaan ohjelmistoalustan applikaatiokoodarin käyttöön tarjoamia ajastimia. Mainitaan vielä sen verran, että systeemi tukee useamman eri käyttöjärjestelmän päälle rakennettuja, erilaisella rajapinnalla varustettuja ajastimia.

Kas joitain aikoja sitten olin tilanteessa, jossa katsoin että useiden erilaisten ajastimien testaus olisi hyväksi. Tuijotin jossain määrin toivottomana noin viittätoista erilaista ajastimen luontifunktiota, joille kaikille pystyi vielä antamaan varsin erilaisia toimintamoodeja parametreilla. Lisäksi ajastimet käyttivät kahta täysin erilaisia ajanlaskusysteemiä, toisessa tiksuteltiin numeroa aina vain isommaksi, tietyn ajan välein, toinen taas muistutti seinäkelloa, (joka siis koostuu sekunneista, minuuteista ja tunneista, jotka kaikki pyörähtävät ympäri kasvattaen suurempaa yksikköä, kunnes vuorokauden vaihtuessa kello pyörähtää ympäri alkutilaansa) tosin kolmen erilaisen aikayksikön sijasta tässä oli viisi erilaista yksikköä, ja "kellon ympäri" mentiin hieman alle minuutissa.

Mietin miten ihmeessä saisin kaikki ajastimet testattua suunnilleen samalla tavalla.

Mietittyäni tovin huomasin kaikkien ajastimien testauksen lopulta vaativan tietyt samankaltaiset askeleet.

1. ajastimen luonti.
2. ajastimen "expiroitumisen" oikeanaikaisuuden tarkistaminen.
3. mahdollisen jaksoittaisen ajastimen peruuttaminen.

Hieman tarkennettuna lista näytti tältä:

1. ajastimen parametrien generointi
2. ajastimen parametrien oikeellisuuden tarkistus. (ajastimen toiminta virheellisiä parametreja käytettäessä on toki myös tarkistettava, mutta testisysteemin tulee osata odottaa oikeaa käytöstä), ja ajastimen jaksollisuuden tarkistus.
3. Ajastimen luonti
4. oletetun laukeamisajan laskeminen
5 laukeamisen odottaminen ja laukeamisajan tarkistus
6 uuden laukeamisajan laskenta jaksolliselle ajastimelle
7.jaksollisen ajastimen (ja laukeamatta jääneen) ajastimen peruuttaminen.
8. virhetilanteen raportointi, ja paluuarvon generointi.

Mekaaninen älämietivaantee C tyylin lähestymistapa olisi ollut kirjoittaa tällainen runko, kopioida se 15 eri tiedostoon, ja lisätä joka runkoon eri ajastintyypille sopivat funktiot + kirjoittaa mahdollisesti vielä sekakäyttöstressitesti.

Totesin, että ei millään, noin tappavan tylsään urakkaan en lähde!

Mieleeni tuli C++:n virtuaaliluokat, joiden avulla C++ koodari saisi kaiken menemään yhteen runkoon. Ja voila...

Aloitin ensin viidestä samankaltaisesta ajastimesta, ja kirjoitin C structin, jota käytin C++:n luokan tyylisesti, eli sijoitin struktiin sekä toiminnallisuuden, että datan. Toisin sanoen, aloitin toteuttamalla yllälistatut funktiot, ja sijoitin struktiin osoittimet ylläminitun tyyppisiin funktioihin. Parametrina kaikille funktioille taas annettiin osoitin tähän struktiin. Lisäksi sijoitin struktiin funktiopointterit struktin "init ja uninit" funktioihin. Kaikki funktiosta toiseen välitettävät datamuuttujat sitten sijoitin myös kyseiseen struktiin.

Ehh.. Nyt kun luen tuon tekstin, en ymmärrä itsekkään mitä oikein tarkoitan :D Eli kirjoitan hyyyvin yksinkertaisen esimerkin:

typedef void (*lampunSytytin)(lamppuesimerkki *_this);
typedef void (*lampunSammutin)(lamppuesimerkki *_this);
typedef void (*lampunAlustin)(lamppuesimerkki *_this);
typedef void (*lampunPoistin)(lamppuesimerkki *_this);

typedef struct lamppuesimerkki
{
Slamppu *lamppuStrukti;
lampunSytytin sytyta;
lampunSammutin sammuta;
lampunAlustin alusta;
lampunPoistin poista;
}lamppuesimerkki;

jossa siis sytyta, sammuta, alusta ja poista ovat funktio-osoittimia.

Esim:

void sytyta(lamppuesimerkki* _this)
{
_this->paalla=1;
}
void sammuta(lamppuesimerkki* _this)
{
_this->paalla=0;
}
void alusta(lamppuesimerkki *_this)
{
_this->lamppuStrukti=getLamppu();
_this->sytyta=&sytyta;
_this->sammuta=&sammuta;
_this->alusta=&alusta;
_this->poista=&poista;
]
void poista(lamppuesimerkki *_this)
{
releaseLamppu(_this->lamppuStrukti);
}

Ja samanlaiset funktiot energiansäästölampulle.

Sitten tein rungon, jossa ensin kutsutaan alustusfunktiota, ja sitten kutakin testifunktiota, ja lopuksi palautetaan tulos. Tai itse asiassa, erotin jo tässä vaiheessa parametrien generoinnin omaksi pieneksi for-looppi-häkkyräksi, joka ei ollut osa struktia. Tästä for looppi häkkyrästä sitten välitettiin ajastimen tyyppi ja parametrit "testienginelle", joka osasi sitten kutsua oikeaa alustusfunktiota, ja antaa parametrit sille. (sijoitin parametrit Em struktiin data-alueelle, ja parametrien generoinnin jälkeen, kun "testi-instanssi" tehtiin (strukti luotiin), siihen sijoitettiin parametristrukti jo ennen init funktion kutsumista. Huomautettavahan se on tässävaiheessa, että kaikille ajastimille minun ei suinkaan tarvinnut toteuttaa kaikkia funktioita erikseen. Osa funktioista sopi useammalle kuin yhdelle ajastimelle.

Lisäsin tässä vaiheessa testirunkoon vielä uuden säikeen generoinnin / instanssi, jolloin for-loopista voitiin laukaista useita yhdenaikaisia testi-instansseja pyörimään.

Seuraavaksi huomasin, että lisäämällä struktin data-alueelle muutaman uuden muuttujan, sain parilla uudella funktiolla tehtyä toimivan testin vielä viidelle muulle ajastimelle.

Ja sitten vielä muutama uusi funktio, ja loputkin ajastimet voitiin testata käyttämällä samaa testirunkoa, hieman erilaisilla parametrien generointi loopeilla. Samoin pelkkää parametrigeneraattoria muuttamalla pystyi testaamaan erilaisten ajastimien yhteiskäyttöä.

Kun testit olivat valmiit, huomasin tässä struktitoteutuksessa vielä erään edun. Ajastinstrukti sisälsi oikeastaan kaiken (missä tahansa testin vaiheessa) tarvittavan datan, ja osoitin struktiin meni jokaisen funktion argumentiksi. Nyt siis pysäyhdyttäessä debuggerilla mihin tahansa testin kohtaan, on oikeastaan lähes kaikki info myös testin aikaisemmasta suorituksesta tallessa ja näkyvissä. Lisäksi erilaisten debuggi-infojen keräily on helppoa, koska kiinnostavissa kohdissa testin tarvitsee vain välittää kopio structista infoja keräilevälle ja tallettavalle prosessille. Niinpä testin kylkeen tuli koodailtua "event" systeemi, eli kiinnostavissa kohdissa testi dumppaa struktin kopion rengaspuskuriin, jota matalampi prioriteettinen säie purkaa. Purkavalle säikeelle on mahdollista rekisteröidä callback-fuinktioita kiinnostavista kohdista tulevan datan käsittelyyn, ja näin voidaan testistä saada ulos mm. erilaisia statistiikkoja, testin suorituksen juurikaan kärsimättä.

Ehkä suuriimat hyödyt tämänkaltaisesta suunnittelusta saadaan silloin, kun toteutettavana on lukuisia toisistaan poikkeavia kikkuloita, jotka kuitenkin käyttäytyvät saman formaatin mukaan. Ja toisaalta, tällaisella toteutuksella/suunnittelulla saadaan systeemeistä sellaisia, että niihin voidaan helposti muuttaa / lisätä toteutusta. Vielä jos varsinaisessa "rungossa" käytetään sopivasti void osoitinta, sen sijaan että käytetään osoitinta structiin , ja castataan se oikeaksi tyypiksi jonkin ulkoisen syötteen perusteella, voidaan systeemiä muuntaa melkein loputtomiin - joskin sen ymmärtäminen ja sitä mukaa ylläpitäminen saattaa muuttua varsin hankalaksi... (Ts. tämä mahdollistaisi useiden erityyppisten structien käytön saman "enginen" sisällä).

Valgrind yksinkertainen esimerkki.

2009-03-19T21:43:00.014+02:00

Valgrind Esimerkki.

Eli tässä nyt edellisessä blogitekstissä lupaamani esimerkki valgrindin käytöstä. Demotakseni valgrindin toimintaa, kirjoitin seuraavanlaisen yksinkertaisen koodinpätkän, joka äkkinäisestä lukijasta saattaa näyttä ihan hyvältä. Siihen on kuitenkin "piilotettu" pari hyvin arkista bugia, jotka valgrind saattaa meille paljastaa...

yliluku.c:

#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#define TAULUN_KOKO 4

int main()
{
size_t taulun_koko=0xFFFFFFFF;
const char merkkijono[]="foo bar foo bar lorum ipsum foo bar";
char taulukko[TAULUN_KOKO];
char *taulu2;
taulu2=malloc(TAULUN_KOKO);
memset(taulukko,0,TAULUN_KOKO);
memcpy(taulukko,merkkijono,TAULUN_KOKO);
taulun_koko=strlen(taulukko);
memcpy(taulu2,taulukko,taulun_koko);
printf("taulukon sisältö \"%s\"\n",taulukko);
printf("taulu2:n sisältö \"%s\"\n",taulu2);
printf("Taulun Koko Define = %u\n",TAULUN_KOKO);
printf("Taulun Koko strlen = %u\n",taulun_koko);
printf("Taulu2:n koko strlen = %u\n",strlen(taulu2));
return TAULUN_KOKO-taulun_koko;
}

Kas tässä. Huomaatko heti bugit? Et välttämättä, vaikka kyse on näin lyhyestä ja yksinkertaisesta pätkästä. Nyt jos tähän lisätään 10000 kertainen määrä koodia, lukuisia threadeja joilla on pääsy yhteisiin resursseihin, ja paljon monimutkaisempia rakenteita... Ja satunainen crashi... Mahdollisesti sellainen joka tapahtuu vasta tuntien toiminnan jälkeen, tai vain kerran 10 000 ajolla... Voit kuvitella miten työlästä sellaisen selvittäminen on. (Ja jos ongelma tulee esiin kerran 10 000 ajolla, ja mikäli teet laadukasta softaa sillä mahdollisesti tulee jossain vaiheessa olemaan 10 000 käyttäjää.. Sitä paitsi, ohjelmistoteollisuudessa Mr. Murphy osaa aina näytellä osansa. Yleensä ikävimmät viat tuuppaavat tulemaan esiin silloin, kun ne eivät saisi. Esim. juuri kun demoat ohjelmaasi firman tärkeimmälle asiakkaalle..)

No joo. Katsotaan siis mitä valgrind tuumaa. Annetaan komento:

valgrind --log-file=ylilukulogi --leak-check=full -v ./yliluku

Ohjelman tulostus:

[Matti@home ~]$ valgrind --log-file=ylilukulogi2 --leak-check=full -v ./yliluku
taulukon sisältö "foo foo bar foo bar lorum ipsum foo bar"
taulu2:n sisältö "foo foo bar foo bar lorum ipsum foo bar"
Taulun Koko Define = 4
Taulun Koko strlen = 39
Taulu2:n koko strlen = 40

Hmm.. "yllättäen" taulun koot eivät olekkaan yhtäsuuret, ja ne vieläpä vaihtelevat ajokertojen välillä. Myös viimeinen merkki (tai viimeiset merkit) tulostuksessa ovat hieman erikoisia... (Erikoinen merkki ei välttämättä näy selaimessa...)

Tutkitaanpa sitte valgrindin kirjoittama logitiedosto:

==5488== Memcheck, a memory error detector.
==5488== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==5488== Using LibVEX rev 1884, a library for dynamic binary translation.
==5488== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==5488== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==5488== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==5488==
==5488== My PID = 5488, parent PID = 10064. Prog and args are:
==5488== ./yliluku
==5488==
--5488--
--5488-- Command line
--5488-- ./yliluku
--5488-- Startup, with flags:
--5488-- --log-file=ylilukulogi2
--5488-- --leak-check=full
--5488-- -v
--5488-- Contents of /proc/version:
--5488-- Linux version 2.6.27.5-117.fc10.i686 (mockbuild@x86-7.fedora.phx.redhat.com) (gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) ) #1 SMP Tue Nov 18 12:19:59 EST 2008
--5488-- Arch and hwcaps: X86, x86-sse1
--5488-- Page sizes: currently 4096, max supported 4096
--5488-- Valgrind library directory: /home/Matti/valgrind_new//lib/valgrind
--5488-- Reading syms from /lib/ld-2.9.so (0x4a7000)
--5488-- Reading debug info from /usr/lib/debug/lib/ld-2.9.so.debug ..
--5488-- Reading syms from /home/Matti/yliluku (0x8048000)
--5488-- Reading syms from /home/Matti/valgrind_new/lib/valgrind/x86-linux/memcheck (0x38000000)
--5488-- object doesn't have a dynamic symbol table
--5488-- Reading suppressions file: /home/Matti/valgrind_new//lib/valgrind/default.supp
--5488-- REDIR: 0x4c0440 (index) redirected to 0x3803cbc3 (vgPlain_x86_linux_REDIR_FOR_index)
--5488-- Reading syms from /home/Matti/valgrind_new/lib/valgrind/x86-linux/vgpreload_core.so (0x4000000)
--5488-- Reading syms from /home/Matti/valgrind_new/lib/valgrind/x86-linux/vgpreload_memcheck.so (0x4003000)
==5488== WARNING: new redirection conflicts with existing -- ignoring it
--5488-- new: 0x004c0440 (index ) R-> 0x040071b0 index
--5488-- REDIR: 0x4c0610 (strlen) redirected to 0x4007460 (strlen)
--5488-- Reading syms from /lib/libc-2.9.so (0x4cc000)
--5488-- Reading debug info from /usr/lib/debug/lib/libc-2.9.so.debug ..
--5488-- REDIR: 0x5437f0 (rindex) redirected to 0x4007090 (rindex)
--5488-- REDIR: 0x53f6c0 (malloc) redirected to 0x4006c80 (malloc)
--5488-- REDIR: 0x5450d0 (memset) redirected to 0x4008350 (memset)
--5488-- REDIR: 0x5455e0 (memcpy) redirected to 0x40078b0 (memcpy)
--5488-- REDIR: 0x543370 (strlen) redirected to 0x4007440 (strlen)
==5488== Invalid write of size 1
==5488== at 0x4007A07: memcpy (mc_replace_strmem.c:402)
==5488== by 0x8048545: main (yliluku.c:18)
==5488== Address 0x402d02c is 0 bytes after a block of size 4 alloc'd
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)
==5488==
==5488== Invalid write of size 1
==5488== at 0x4007A0F: memcpy (mc_replace_strmem.c:402)
==5488== by 0x8048545: main (yliluku.c:18)
==5488== Address 0x402d02d is 1 bytes after a block of size 4 alloc'd
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)
==5488==
==5488== Invalid write of size 1
==5488== at 0x4007A18: memcpy (mc_replace_strmem.c:402)
==5488== by 0x8048545: main (yliluku.c:18)
==5488== Address 0x402d02e is 2 bytes after a block of size 4 alloc'd
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)
==5488==
==5488== Invalid write of size 1
==5488== at 0x4007A21: memcpy (mc_replace_strmem.c:402)
==5488== by 0x8048545: main (yliluku.c:18)
==5488== Address 0x402d02f is 3 bytes after a block of size 4 alloc'd
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)
==5488==
==5488== Invalid write of size 1
==5488== at 0x4007A57: memcpy (mc_replace_strmem.c:402)
==5488== by 0x8048545: main (yliluku.c:18)
==5488== Address 0x402d04c is not stack'd, malloc'd or (recently) free'd
--5488-- REDIR: 0x548120 (strchrnul) redirected to 0x4008420 (strchrnul)
--5488-- REDIR: 0x545130 (mempcpy) redirected to 0x4008480 (mempcpy)
==5488==
==5488== Invalid read of size 1
==5488== at 0x4007453: strlen (mc_replace_strmem.c:242)
==5488== by 0x50F4CF: vfprintf (in /lib/libc-2.9.so)
==5488== by 0x51591F: printf (in /lib/libc-2.9.so)
==5488== by 0x804856B: main (yliluku.c:20)
==5488== Address 0x402d02c is 0 bytes after a block of size 4 alloc'd
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)
==5488==
==5488== Invalid read of size 1
==5488== at 0x5367DC: _IO_file_xsputn@@GLIBC_2.1 (in /lib/libc-2.9.so)
==5488== by 0x50ED5C: vfprintf (in /lib/libc-2.9.so)
==5488== by 0x51591F: printf (in /lib/libc-2.9.so)
==5488== by 0x804856B: main (yliluku.c:20)
==5488== Address 0x402d04f is not stack'd, malloc'd or (recently) free'd
==5488==
==5488== Invalid read of size 1
==5488== at 0x5367F4: _IO_file_xsputn@@GLIBC_2.1 (in /lib/libc-2.9.so)
==5488== by 0x50ED5C: vfprintf (in /lib/libc-2.9.so)
==5488== by 0x51591F: printf (in /lib/libc-2.9.so)
==5488== by 0x804856B: main (yliluku.c:20)
==5488== Address 0x402d04e is not stack'd, malloc'd or (recently) free'd
==5488==
==5488== Invalid read of size 1
==5488== at 0x4008575: mempcpy (mc_replace_strmem.c:677)
==5488== by 0x5368C2: _IO_file_xsputn@@GLIBC_2.1 (in /lib/libc-2.9.so)
==5488== by 0x50ED5C: vfprintf (in /lib/libc-2.9.so)
==5488== by 0x51591F: printf (in /lib/libc-2.9.so)
==5488== by 0x804856B: main (yliluku.c:20)
==5488== Address 0x402d02c is 0 bytes after a block of size 4 alloc'd
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)
==5488==
==5488== Invalid read of size 1
==5488== at 0x4008568: mempcpy (mc_replace_strmem.c:677)
==5488== by 0x5368C2: _IO_file_xsputn@@GLIBC_2.1 (in /lib/libc-2.9.so)
==5488== by 0x50ED5C: vfprintf (in /lib/libc-2.9.so)
==5488== by 0x51591F: printf (in /lib/libc-2.9.so)
==5488== by 0x804856B: main (yliluku.c:20)
==5488== Address 0x402d02d is 1 bytes after a block of size 4 alloc'd
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)
==5488==
==5488== Invalid read of size 1
==5488== at 0x4007453: strlen (mc_replace_strmem.c:242)
==5488== by 0x804859D: main (yliluku.c:23)
==5488== Address 0x402d02c is 0 bytes after a block of size 4 alloc'd
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)
--5488-- REDIR: 0x53d2b0 (free) redirected to 0x4005aa0 (free)
==5488==
==5488== ERROR SUMMARY: 181 errors from 11 contexts (suppressed: 14 from 1)
==5488==
==5488== 1 errors in context 1 of 11:
==5488== Invalid read of size 1
==5488== at 0x5367DC: _IO_file_xsputn@@GLIBC_2.1 (in /lib/libc-2.9.so)
==5488== by 0x50ED5C: vfprintf (in /lib/libc-2.9.so)
==5488== by 0x51591F: printf (in /lib/libc-2.9.so)
==5488== by 0x804856B: main (yliluku.c:20)
==5488== Address 0x402d04f is not stack'd, malloc'd or (recently) free'd
==5488==
==5488== 3 errors in context 2 of 11:
==5488== Invalid write of size 1
==5488== at 0x4007A57: memcpy (mc_replace_strmem.c:402)
==5488== by 0x8048545: main (yliluku.c:18)
==5488== Address 0x402d04c is not stack'd, malloc'd or (recently) free'd
==5488==
==5488== 8 errors in context 3 of 11:
==5488== Invalid write of size 1
==5488== at 0x4007A21: memcpy (mc_replace_strmem.c:402)
==5488== by 0x8048545: main (yliluku.c:18)
==5488== Address 0x402d02f is 3 bytes after a block of size 4 alloc'd
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)
==5488==
==5488== 8 errors in context 4 of 11:
==5488== Invalid write of size 1
==5488== at 0x4007A18: memcpy (mc_replace_strmem.c:402)
==5488== by 0x8048545: main (yliluku.c:18)
==5488== Address 0x402d02e is 2 bytes after a block of size 4 alloc'd
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)
==5488==
==5488== 8 errors in context 5 of 11:
==5488== Invalid write of size 1
==5488== at 0x4007A0F: memcpy (mc_replace_strmem.c:402)
==5488== by 0x8048545: main (yliluku.c:18)
==5488== Address 0x402d02d is 1 bytes after a block of size 4 alloc'd
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)
==5488==
==5488== 8 errors in context 6 of 11:
==5488== Invalid write of size 1
==5488== at 0x4007A07: memcpy (mc_replace_strmem.c:402)
==5488== by 0x8048545: main (yliluku.c:18)
==5488== Address 0x402d02c is 0 bytes after a block of size 4 alloc'd
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)
==5488==
==5488== 18 errors in context 7 of 11:
==5488== Invalid read of size 1
==5488== at 0x4008568: mempcpy (mc_replace_strmem.c:677)
==5488== by 0x5368C2: _IO_file_xsputn@@GLIBC_2.1 (in /lib/libc-2.9.so)
==5488== by 0x50ED5C: vfprintf (in /lib/libc-2.9.so)
==5488== by 0x51591F: printf (in /lib/libc-2.9.so)
==5488== by 0x804856B: main (yliluku.c:20)
==5488== Address 0x402d02d is 1 bytes after a block of size 4 alloc'd
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)
==5488==
==5488== 18 errors in context 8 of 11:
==5488== Invalid read of size 1
==5488== at 0x4008575: mempcpy (mc_replace_strmem.c:677)
==5488== by 0x5368C2: _IO_file_xsputn@@GLIBC_2.1 (in /lib/libc-2.9.so)
==5488== by 0x50ED5C: vfprintf (in /lib/libc-2.9.so)
==5488== by 0x51591F: printf (in /lib/libc-2.9.so)
==5488== by 0x804856B: main (yliluku.c:20)
==5488== Address 0x402d02c is 0 bytes after a block of size 4 alloc'd
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)
==5488==
==5488== 35 errors in context 9 of 11:
==5488== Invalid read of size 1
==5488== at 0x5367F4: _IO_file_xsputn@@GLIBC_2.1 (in /lib/libc-2.9.so)
==5488== by 0x50ED5C: vfprintf (in /lib/libc-2.9.so)
==5488== by 0x51591F: printf (in /lib/libc-2.9.so)
==5488== by 0x804856B: main (yliluku.c:20)
==5488== Address 0x402d04e is not stack'd, malloc'd or (recently) free'd
==5488==
==5488== 37 errors in context 10 of 11:
==5488== Invalid read of size 1
==5488== at 0x4007453: strlen (mc_replace_strmem.c:242)
==5488== by 0x804859D: main (yliluku.c:23)
==5488== Address 0x402d02c is 0 bytes after a block of size 4 alloc'd
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)
==5488==
==5488== 37 errors in context 11 of 11:
==5488== Invalid read of size 1
==5488== at 0x4007453: strlen (mc_replace_strmem.c:242)
==5488== by 0x50F4CF: vfprintf (in /lib/libc-2.9.so)
==5488== by 0x51591F: printf (in /lib/libc-2.9.so)
==5488== by 0x804856B: main (yliluku.c:20)
==5488== Address 0x402d02c is 0 bytes after a block of size 4 alloc'd
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)
--5488--
--5488-- supp: 14 dl-hack3-cond-1
==5488==
==5488== IN SUMMARY: 181 errors from 11 contexts (suppressed: 14 from 1)
==5488==
==5488== malloc/free: in use at exit: 4 bytes in 1 blocks.
==5488== malloc/free: 1 allocs, 0 frees, 4 bytes allocated.
==5488==
==5488== searching for pointers to 1 not-freed blocks.
==5488== checked 48,172 bytes.
==5488==
==5488==
==5488== 4 bytes in 1 blocks are definitely lost in loss record 1 of 1
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)
==5488==
==5488== LEAK SUMMARY:
==5488== definitely lost: 4 bytes in 1 blocks.
==5488== possibly lost: 0 bytes in 0 blocks.
==5488== still reachable: 0 bytes in 0 blocks.
==5488== suppressed: 0 bytes in 0 blocks.
--5488-- memcheck: sanity checks: 0 cheap, 1 expensive
--5488-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--5488-- memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10
--5488-- memcheck: auxmaps_L2: 0 searches, 0 nodes
--5488-- memcheck: SMs: n_issued = 9 (144k, 0M)
--5488-- memcheck: SMs: n_deissued = 0 (0k, 0M)
--5488-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M)
--5488-- memcheck: SMs: max_undefined = 0 (0k, 0M)
--5488-- memcheck: SMs: max_defined = 25 (400k, 0M)
--5488-- memcheck: SMs: max_non_DSM = 9 (144k, 0M)
--5488-- memcheck: max sec V bit nodes: 0 (0k, 0M)
--5488-- memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0)
--5488-- memcheck: max shadow mem size: 448k, 0M
--5488-- translate: fast SP updates identified: 1,765 ( 89.8%)
--5488-- translate: generic_known SP updates identified: 108 ( 5.4%)
--5488-- translate: generic_unknown SP updates identified: 92 ( 4.6%)
--5488-- tt/tc: 3,939 tt lookups requiring 3,969 probes
--5488-- tt/tc: 3,939 fast-cache updates, 3 flushes
--5488-- transtab: new 1,840 (39,574 -> 566,109; ratio 143:10) [0 scs]
--5488-- transtab: dumped 0 (0 -> ??)
--5488-- transtab: discarded 5 (113 -> ??)
--5488-- scheduler: 23,126 jumps (bb entries).
--5488-- scheduler: 0/2,143 major/minor sched events.
--5488-- sanity: 1 cheap, 1 expensive checks.
--5488-- exectx: 769 lists, 207 contexts (avg 0 per list)
--5488-- exectx: 397 searches, 216 full compares (544 per 1000)
--5488-- exectx: 0 cmp2, 397 cmp4, 0 cmpAll
--5488-- errormgr: 22 supplist searches, 981 comparisons during search
--5488-- errormgr: 195 errlist searches, 507 comparisons during search

Oh Hoh... johan paukahti.

Ensin näemme nipun valgrindin käynnistystietoja, kuten peruskäskyjen uudelleenohjauksen. Sitten alkaa varsinaiset tuotokset minun koodini osalta. Ensin nippu kirjoituksia häröosoitteisiin

==5488== Invalid write of size 1
==5488== at 0x4007A07: memcpy (mc_replace_strmem.c:402)
==5488== by 0x8048545: main (yliluku.c:18)
==5488== Address 0x402d02c is 0 bytes after a block of size 4 alloc'd
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)

ja kumppanit. Tarkataanpa tätä hetki. Ensin on kerrottu mikä vika on löydetty. Eli kuten jo totesin, häröosoitteeseen kirjoitus, kirjoitettavan datan ollessa 1 tavu.
Sitten call trace kohdasta jossa ylikirjoitus tapahtui. Eli main() funktiosta riviltä 18 alkoi kutsujen nippu, joka päättyi ylikirjoitukseen memcpy() funktiossa.

memcpy(taulu2,taulukko,taulun_koko);

Ja viimeiset pari riviä kertovat kirjoituksen osuneen heti rivillä 14 allokoidun muistipalan perään.

Eli olemme siis ylikeirjoittaneet memcpy lausekkeessamme taulu2 viimeisen indeksin yli...

Mutta miksi?
Vastauksen kerron lopussa ;)

Skipataanpa muiden memcpy:stä tulleiden varoitusten ohi (oh, tämä muuten näyttää sille, että memcpy kirjoitti datan tavu kerrallaan... Aika yllätys minulle). Seuraavaksi tuleekin vastaan Invalid Read:eja

==5488== Invalid read of size 1
==5488== at 0x4007453: strlen (mc_replace_strmem.c:242)
==5488== by 0x50F4CF: vfprintf (in /lib/libc-2.9.so)
==5488== by 0x51591F: printf (in /lib/libc-2.9.so)
==5488== by 0x804856B: main (yliluku.c:20)
==5488== Address 0x402d02c is 0 bytes after a block of size 4 alloc'd
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)

Jälleen ensimmäisenä on tapahtunut virhe, eli luku häröosoitteesta. Sitten jälleen calltrace, ja lähellä majailevan allokoidun muistialueen allokointikohta. Eli rivin 20 printti on siis käyttänyt sisällään strlen() funktiota (tuntuu loogiselta, printti halunnee tietää kuinka pitkästi dataa on printattava käytettäessa %s muotoilua). strlen funktio puolestaan on lukenut yli taulu2 lopun. Toisin sanoen taulu2 muuttujamme ei ole ollut kunnolla "NULL terminoitu", eli ei ole sisältänyt viimeistä NULL merkkiä, ilmoittamassa tekstistringin loppumisesta. Ihan luonnollista koska aiemmin memcpyssä kirjoitimme taulukon lopun yli...

No nyt on hyvä hetki näyttää myös valgrindin heikkous. Eli ensimmäinen tapahtunut virhe jäi valgrindilta huomaamatta.

Rivillä 17 (tarkistettaessa taulukko taulukossa olleen tekstistringin pituutta strlen() funktiolla), on ensimmäisen kerran suoritettu luku väärästä paikasta. Ylempänä kopioitaessa tekstiä taulukko muuttujaan, kopioimme koko taulukon mitalta - siis myös viimeisen NULL merkin yli. seuraava strlen() lukee taulukko[0]:n osoitteesta alkaen kunnes löytää '\0' merkin. Koska kirjoitimme juuri sen yli, strlen lukee iloisesti yli taulukko muuttujamme rajojen, saaden stringin pituudeksi huomattavasti pidemmän pätkän kuin pitäisi. Ilmeisesti kuitenkin tämä luku sattui testiprosessimme stackin alueelle, sillä valgrind ei huomannut sitä. Nyt seuraava memcpy kopioi kuitenkin strlen() ilmoittaman (liian pitkän) pituuden verran dataa, joten loppuosa kopioinnista menee taulu2 rajojen yli. Tästä siis valgrindin ensimmäinen herja.

Loppu onkin jo itsestään selvää. Eli printatessamme taulukko ja taulu2 muuttujien sisällöt tekstinä, printf:n kutsuma strlen() lukee jälleen yli rajojen. Ja kaiken kruunaa vielä valgrind raportin lopussa oleva:

==5488== 4 bytes in 1 blocks are definitely lost in loss record 1 of 1
==5488== at 0x4006D3E: malloc (vg_replace_malloc.c:207)
==5488== by 0x80484E6: main (yliluku.c:14)

Eli allokoidun muistin vapauttaminen pääsi unohtumaan... ;)

C - kieli, vikojen etsintä.

2009-03-17T23:35:00.009+02:00

Debuggerit (erityisesti gdb)

Ensimmäistä ohjelmapätkää C:llä koodatessani vietin tunteja etsien indexivirhettä for loopeistani. (Ensimmäinen ohjelmani oli muuten koodinpätkä, joka korvasi parametrina annettuja stringejä, toisilla - tehty silloisten kotisivujeni linkkiosion päivitykseen). Vian etsimiseen käytin printtejä. Tulostin muuttujan arvon toisensa jälkeen, ja yritin löytää kohdan jossa ohjelma kaatui... Printit ovat toki edelleen tehokas keino virheiden etsintään, mutta vuosien aikana olen tutustunut moniin tehokkaisiin ohjelmiin jotka helpottavat vikojen löytämistä.

Debuggerit:

Toivotko joskus että voisit nähdä muuttujien arvot ohjelman suorituksen aikana? Haluaisitko seurata ohjelman ajoa rivi riviltä, nähden miten suoritus hyppii kutsusta toiseen? Tämä on mahdollista debuggerin avulla. Muutamien windows koodaajien olen kuullut kehuvan MS visual studio 2005 mukana tulevaa debuggeria. Itse en ole kyseiseen vempeleeseen tutustunut, sillä windows on kaiken kaikkiaan aika outo alusta minulle. Linuxilla taas tunnetuin debuggeri on gdb, joka yleensä löytyy kaikkien distrojen pakettienhallinnasta. Puhdas gdb voi olla aika hankala käyttää ensi alkuun, sillä se on puhtaasti komentorivipohjainen. Onneksi gdb:n mukana tulee hyvä "helppi", jota voit käyttää myös kesken debuggauksen kirjoittamalla yksinkertaisen komennon "help" tai "help <gdbn_komento>". Lisäksi gdb:tä käyttämään on tehty useita graafisia ohjelmia. Itse olen käyttänyt Eclipse IDE:ä, joka siis sisältää debuggerin lisäksi koodieditorin, käännösnapit jne. Eclipse ei kuitenkaan ole maailman käyttäjäystävällisin mitä tulee projektin luontiin. (ainakaan vanhemmat versiot eivät olleet). Toinen graafinen käyttöliittymä gdb:lle jota olen käyttänyt on ddd. Ddd on oikeastaan vain käyttöliittymä gdb:lle, ilman mitään ylimääräisiä lisäosia.

Jotta saat täyden hyödyn debuggeristasi, tulee sinun käännösvaiheessa sisällyttä "debuggi-infot" kääntämääsi binääriin. Tällöin debuggeri osaa näyttää kutsuttujen funktioiden nimet, ja kooditiedostot + rivinumerot ajon aikana. Gcc kääntäjällä, debuggi-infot saat binääriin käyttämällä käännöksessä -g (tai -ggdb) flagia. Esim:

gcc -ggdb -o testiohjelma testiohjelmakoodi.c

Ja ihan peruskomennot, joilla gdb:n kanssa pääsee alkuun:

Gdb käynnistetään kertomalla sille ajettavan binäärin nimi, tai vaihtoehtoisesti suoritettvan ohjelman ajokomento parametreineen --args vivun keralla.

gdb testiohjelma
tai
gdb --args ./testiohjelma parametri1 parametr2 parametri3...

Tämä käynnistää gdbn, joka lukee ajettavan binäärin, ja lataa tarvittavat (ja saatavilla olevat) debuggitiedot. Muista, että C ohjelmasi on tehty standardikirjastojen päälle. Mikäli siis olet asentanut debuggiversiot standardikirjastoista ja linkannut ohjelmasi niitä vasten, voit sujuvasti kurkistella myös standardikirjastojen toteutuksen sisään.

Tässä vaiheessa ohjelma on siis ladattuna gdb:n sisään, mutta ei ole vielä ajossa. Ohjelman ajon aikana et voi kskyttää gdb:tä, joten nyt on hyvä aika asettaa mahdolliset breakpointit (joihin tultaessa ohjelma pysähtyy), signaalien käsittelyt jne. Sen jälkeen kun ajat ohjelman gdb:n sisällä, voit pysäyttää gdb:n antamalla näppäimistöltä interrupt signaalin SIG_INT (ctrl+c). Tämä tosin pysäyttää ohjelman ajon satunnaiseen paikkaan, mikä harvoin on kannattavaa, ellet halua muuttaa joitain gdb:n asetuksia, kuten breakpointteja tms. (listaan komentoja jäljempänä)

Tyypillisin ja helpoin gdb:n käyttötapa on seuraava:

Sinulla on ohjelma foo joka kaatuu segmentation Fault ilmoituksen kanssa. (lue aiemmat tekstini muistinkäytöstä mikäli segmentation fault on hämärä käsite).

Ladataan ohjelma gdb:hen

gdb --args ./foo fooparameters
tai
gdb foo

ajetaan ohjelma:

run
tai
run fooparameters

odotetaan että ohjelma saavuttaa kaatumispisteensä...

Kun MMU (memory management unit) huomaa userspace ohjelman (joita kaikki normaali applikaatiot ovat) pyrkivän accessoimaan muistiosoitteeseen jota sille ei ole "mapattu" käyttöön (esim. kirjoittamalla alustamattomaan osoittimeen, tai taulukon rajojen yli), se herättää kernelin, joka (tavallisesti) lähettää SIGSEGV signaalin ohjelmalle. Normaalisti ohjelman saadessa SIGSEGV signaalin, se lopettaa suorituksensa Segmentation Fault ilmoituksen kera (ellei jotain handleria ole rekisteröity - mihin en nyt puutu). Debuggerilla ajettaessa debuggeri kuitenkin "poimii" signaalin, ja pysäyttää ohjelman suorituksen ongelmakohtaan (kohtaan jossa varsinainen laiton muistiaccessi tapahtui - todellinen ongelma tosin on voinut sattua jo aiemmin). gdb myös näyttää koodirivin jolla kirjoitus/luku tapahtui.

Mikäli kyseisessä kohdassa ei näytä olevan mitään erikoista, tai mikäli ollaan jonkin standardikirjaston sisäisessa kutsussa, käyttäjä yleensä antaa komennon
bt
joka näyttää pinosta funktiot, joiden kautta kaatumispisteeseen on tultu. Kuljetut funktiot on numeroitu siten, että tuoreempi funktiokutsu saa pienemmän numeron. Näitä kutsukohtia voi sitten pomppia eteen ja taaksepäin komennolla
frame
kunnes pääsee kohtaan jossa epäilee ongelman mahdollisesti majailevan. Nyt esim osoittimien osoittaman muistin tilan (tai tavallisen muuttujan sisältämän datan) voit tarkistaa komentamalla
inspect muuttujannimi
tai
inspect muistiosoite.
Mikäli sinulla on osoitin johonkin datarakenteeseen, voit tutkia koko rakenteen datan helposti komennolla
inspect *osoitinmuuttujannimi
tai tietyn jäsenen sisältämä datan
inspect osoitinmuuttujannimi->jäsen.

Mutta ennen kuin tämä osio venyy kohtuuttoman kauas, lopetan yksityiskohtaisen kerronnan, ja sanon pari varoituksen sanaa + listaan liudan käteviä komentoja:

VaRoItUs! Erityisesti useampisäikeisissä ohjelmissa on tyypillistä, että koodarit tekevät ikäviä synkronointibugeja, eli sallivat useamman säikeen käpistelevän jotain jaettua resurssia samanaikaisesti. Ikäviä näistä bugeista tekee se, että niiden laukeaminen on hyvin satunnaista, ja erityisen ajoituskriittistä. Kun ohjelmaa ajetaan debuggerissa, ohjelman suoritus hidastuu debuggerin pitäessä kirjaa tapahtumista => usein ajoituskriittiset viat jotka tulevat esiin ilman debuggeria ajettaessa, eivät tule esiin debuggerin kanssa - ja päinvastoin...

sitten se lupaamani
lista gdb:n peruskomennoista:

ohjelman ajo:
run

pysäytyskohdan asettaminen:
break funktionnimi
tai
break tiedostonnimi:rivinumero

ehdollinen pysäyttäminen:
aseta pysäytyskohta kuten edellä, ja pane merkille pysäytyskohdan numero
tee ehto:
condition
esim:
condition 1 muuttuja == 5

signaalien käsittely:
handle
tai
handle
(kertoo tämänhetkisen signaalin käsittelytavan)
tämän jälkeen voit muuttaa kyseisiä käsittelytapoja määrittämällä pysäytetäänkö ohjelman suoritus signaalin saapuessa, printataanko signaalin tulo ja päästetänkö signaali ajettavalle ohjelmalle.
handle stop print pass
esim.
handle SIGILL
handle SIGILL nostop noprint pass

Säikeet saat listattua (ja tiedon siitä mitä säikeet ovat tekemässä) käyttämällä komentoa:
info threads

ja säikeestä toiseen voit hypätä komennolla
thread numero

paikalliset muuttujat saat esille komennolla
info locals

Muuttujien sisältämää dataa pääsee tutkimaan paitsi inspect komennolla, myös komennolla
x
x-komento sallii sinun näyttävän myös haluamasi määrän dataa tietystä muistiosoitteesta (tai osoitinmuuttujan osoittamasta osoitteesta). Erityisen kätevä x komento on kaivettaessa dataa suuresta void muuttujasta, esim muistipoolin alusta. koko syntaksi on

x/ osoite/osoitinmuuttuja

jossa näyttöformaatti voi olla o=octaali, x=heksadesimaali, d=desimaali, u=unsigned desimaali, t=binari, f=liukuluku, a=osoite, i=käsky, c=merkki s=merkkijono.
datatyyppi (eli datan koko) voi olla b=tavu, h=2 tavua(short), w=4 tavua(int), g=8 tavua (64 bittiä)

eli esimerkkinä. Minulla on taulukko int foo[100], jonka alkuun osoittaa osoitin void *bar. Voin siis käskeä esim:
x/100xw bar
tämän pitäisi tulostaa 100 kappaletta (w) 4:n tavun kokoisia datakönttejä (x)heksadesimaalimuodossa.

Ohjelmasta voit irroittautua komennolla
detach
jolloin debuggeri jättää ohjelman ajelemaan yksikseen.

tiedostolistauksen saat komennolla
list
joka näyttää 10 riviä kohdasta johon olet juuri pysähtynyt, tai edellisen listauksen loppukohdasta. Voit myös määrittää tiedosto ja rivin jolta alkaen haluat nähdä 10 riviä, tai funktion jonka alusta haluat nähdä 10 riviä komennolla:
list funktionnimi
tai
list tiedostonnimi:rivinumero

Watchpoint muuttujan int foo sisällölle nimen ja osoitteen perusteella:

watch foo [threadinnumero mikäli rautawatchpointti]
watch (int)0xB00BBABE [threadinnumero mikäli rautawatchpointti]

Eli jälkimmäisessä siis oletetaan, että muuttuja foo on talletettu osoitteeseen 0xB00BBABE. Oikean osoitteen saat selville käskyllä

print &foo

Lisää watchpointeista

Valgrind:

Debuggerin kaverina on hyvä olla jokin muistinanalysointityökalu, jolla voit helposti paikantaa luvut/kirjoitukset yli varatun tilan, alustamattomien muuttujien käytön, muistivuodot jne. Jälleen windows maailma on minulle hieman outo, mutta linuxilla olen käyttänyt mm. valgrind nimistä työkalua.

valgrind --log-file=foo --leak-check=full -v ./ajettavaohjelma

ajaa ohjelman valgrind nimisessä "hiekkalaatikossa", memcheck nimisen muistinanalysointiohjelman alla, tehden foo.prosessiId nimisen logitiedoston, johon liitetään myös täysi muistivuotoanalyysi, ja vielä verbose (mahdollisimman paljon tietoa) moodissa.
Pienen esimerkkilogin ja sen analyysin koetan räpeltää tänne lähipäivinä, kunhan vain ennättäisin...

To Be Continued... ...later :)

ANSI C explode.

2008-09-16T16:50:00.017+03:00

13.09.2011: Allaoleva linkki päivitetty (taas)
16.02.2010 YeeeHaw farmarit! Vai miten se pärstäkirjan suosikkiapplikaatio sen sanoikaan... Jokatapauksessa, SVN on taas pystyssä! http://xp-dev.com/svn/MazBotV4/trunk/
(generic/src kansiosta löytynee kaikki kiinnostava materiaali)

09.02.2010 Moro! Ikäviä uutisia, mutta SVN repositorio jota käytän kehitysversion ylläpitoon on tällähaavaa ongelmien kourissa. Ilmoittelen ja korjaan asioita sitämukaa kun ehdin :(

02.02.2010: Olinpa aikaansaapa. Tekaisin pikaisen API dokumentaation Cexplodesta ja muista funktioista jotka sisältyvät bottiprojektini "helperseihin". Dokumentaatio löytyy täältä. Tämänhetken filut (helpers.h ja helpers.c) ovat täällä. Makefilen joudutte itse kyhäämään, mutta se ei liene kauhean vaikeaa :) Ja jos nyt ihan ylitsepääsemättömiä ongelmia tulee, mutta haluaisitte kuitenkin käyttää funktioita, niin pieni kommentti tänne/sähköposti osoitteeseen Mazziesaccount@gmail.com, ja saatan tehdä tuosta ihan jonkinlaisen ladattavan zipin.
Ja vielä pieni pyyntö: raportoikaa kaikki bugiloiset tänne, siitä on minulle iiiiso apu! :)

Hups. Bugin pannahinen piileskelee allaolevassa versiossa - älkää käyttäkö.
Otin tämän Cexploden käyttöön uudessa bottiprojectissani, ja siellä siihen myös ilmaantuu muutamia lisäosasia tarpeen mukaan...

Täältä löydätte suht testatun ja suht stabiilin version (Cexplode löytyy nyt kansiosta generic/src/, tiedostot helpers.c ja helpers.h.)
http://xp-dev.com/svn/Mazzie-mazbot/
(subversion repository)
Tiedostoissa on joitain muitakin funktioita, ja mikäli käännösherjoja tulee, kannattaa koettaa raapia ne pois.

Allaolevassa kommentissa on linkki kehitysversioon botista, ja siinä olevan koodin toimivuudesta ei ole mitään takeita... Toisinaan se ei edes käänny :)

Monet blogini lukijat ovat etsineet C/C++ kielistä toteutusta php:n explode funktiolle. Päätin siis kirjoitella moisen, ja tässä se nyt sitten on.

Pari sanaa kuitenkin ennen lähdekoodin näyttöä:

1. Thread safety/re-entrancy.

Suurimpana ongelmana standardikirjaston strtok:ssa nään sen, ettei se ole monisäikeiseen ohjelmaan soveltuva. (siitä kirjoittelin edellisessä blogitekstissäni). Tämäkään Cexplode ei takaa monisäikeiseen ohjelmointiin soveltuvuutta, sillä siinä käytetään standardikirjaston strlen(), memcmp(), malloc(), free() ja realloc() funktioita. Kuitenkin mikäli teette ohjelmaa normaaliin nykyaikaiseen PC käyttöön, käyttäen normaaleja standardikirjastoja, on melko turvallista olettaa kyseisten funktioiden toimivan myös monisäikeisissä ohjelmissa. (Syynä on se, ettei em. funktioiden implementointi oikeastaan vaadi minkään ei re-entrantin ominaisuuden käyttöä - ja nykyään säikeiden käyttö on enemmänkin sääntö kuin poikkeus => kirjastot pyritään tekemään monisäikeiseen ohjelmaan soveltuviksi vaikkei C:n standardit sitä vaadi.)

2. ongelmat Cexplode:n käytössä.

Lue esimerkki. Mikäli jotain jää epäselväksi, kysy :)

3. Muokkaus ja käyttö.

Koodipätkää saa vapaasti käyttää, mutta mikäli muokkaat siitä parannetun version tulee sinun postata parannettu versio kommenttina joko tähän blogiin, tai http://maz-programmersdiary.blogspot.com/ blogiini, tai laittaa se minulle sähköpostilla osoitteeseen Mazziesaccount@gmail.com

Koetan ehtiä jossain välissä laittaa pakatut tiedostot ladattavaksi, mutta tällähetkellä saatte vain allaolevan copy-pastattavan version.

Cexplode.h

/* ******************************************************** */
/*                                                          *
*      Implementation of php's explode written in C        *
*      Written by  Maz (2008)                              *
*      http://maz-programmersdiary.blogspot.com/           *
*                                                          *
*      You're free to use this piece of code.              *
*      You can also modify it freely, but if you           *
*      improve this, you must write the improved code      *
*      in comments at:                                     *
*      http://maz-programmersdiary.blogspot.com/           *
*      or at:                                              *
*      http://c-ohjelmoijanajatuksia.blogspot.com/         *
*      or mail the corrected version to me at              *
*      Mazziesaccount@gmail.com                            *
*                                                          *
*      Revision History:                                   *
*                                                          *
*      -v0.0.1 16.09.2008/Maz                              *
*                                                          */
/* ******************************************************** */

#ifndef CEXPLODE_H
#define CEXPLODE_H

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

typedef struct CexplodeStrings
{
int amnt;
char **strings;
}CexplodeStrings;

typedef enum ECexplodeRet
{
ECexplodeRet_InternalFailure    = -666,
ECexplodeRet_InvalidParams         = -667
}ECexplodeRet;

int Cexplode
(
const char *string,
const char *delim,
CexplodeStrings *exp_obj
);
char *Cexplode_getNth(int index,CexplodeStrings exp_obj);
char *Cexplode_getfirst(CexplodeStrings exp_obj);
void Cexplode_free(CexplodeStrings exp_obj);


#endif

Cexplode.c

/* ******************************************************** */
/*                                                          *
*      Implementation of php's explode written in C        *
*      Written by  Maz (2008)                              *
*      http://maz-programmersdiary.blogspot.com/           *
*                                                          *
*      You're free to use this piece of code.              *
*      You can also modify it freely, but if you           *
*      improve this, you must write the improved code      *
*      in comments at:                                     *
*      http://maz-programmersdiary.blogspot.com/           *
*      or at:                                              *
*      http://c-ohjelmoijanajatuksia.blogspot.com/         *
*      or mail the corrected version to me at              *
*      Mazziesaccount@gmail.com                            *
*                                                          *
*      Revision History:                                   *
*                                                          *
*      -v0.0.1 16.09.2008/Maz                              *
*                                                          */
/* ******************************************************** */


#include "Cexplode.h"


int Cexplode
(
const char *string,
const char *delim,
CexplodeStrings *exp_obj
)
{
int stringL = 0;
int delimL  = 0;
int index;
int pieces=0;
int string_start=0;

char **tmp=NULL;

//Sanity Checks:
if(NULL==string || NULL==delim || NULL == exp_obj)
{
    printf("Invalid params given to Cexplode!\n");
    return ECexplodeRet_InvalidParams;
}
stringL = strlen(string);
delimL  = strlen(delim);
if(delimL>=stringL)
{
    printf("Invalid params given to Cexplode!\n");
    return 0;
}
for(index=0;index<stringL-delimL;index++)
{
    if(string[index]==delim[0])
    {
        //Check if delim was actually found
        if( !memcmp(&(string[index]),delim,delimL) )
        {
            //token found
            //let's check if token was at the beginning:
            if(index==string_start)
            {
                string_start+=delimL;
                index+=delimL-1;
                continue;
            }
            /*
               if token was not at start, then we
               should add it in CexplodeStrings
            */
            pieces++;
            if(NULL==tmp)
                tmp=malloc(sizeof(char *));
            else
                tmp=realloc(tmp,sizeof(char *)*pieces);
            if(NULL==tmp)
            {
                printf("Cexplode: Malloc failed!\n");
                return ECexplodeRet_InternalFailure;
            }
            //alloc also for \0
            tmp[pieces-1]=malloc
            (
              sizeof(char *)*(index-string_start+1)
            );
            if(NULL==tmp[pieces-1])
            {
                printf("Cexplode: Malloc failed!\n");
                return ECexplodeRet_InternalFailure;
            }
            memcpy(
              tmp[pieces-1],
              &(string[string_start]),
              index-string_start
            );

            tmp[pieces-1][index-string_start]='\0';
            string_start=index+delimL;
            index+=(delimL-1);
        }//delim found
    }//first letter in delim found from string
}//for loop

if(memcmp(&(string[index]),delim,delimL))
    index+=delimL;
if(index!=string_start)
{
    pieces++;
    if(NULL==tmp)
        tmp=malloc(sizeof(char *));
    else
        tmp=realloc(tmp,sizeof(char *)*pieces);
    if(NULL==tmp)
    {
        printf("Cexplode: Malloc failed!\n");
        return ECexplodeRet_InternalFailure;
    }
        tmp[pieces-1]=malloc
       (
          sizeof(char *)*(index-string_start+1)
       );
    if(NULL==tmp[pieces-1])
    {
        printf("Cexplode: Malloc failed!\n");
        return ECexplodeRet_InternalFailure;
    }
    memcpy
    (
      tmp[pieces-1],
      &(string[string_start]),
      index-string_start
    );
    tmp[pieces-1][index-string_start+1]='\0';
}
exp_obj->amnt=pieces;
exp_obj->strings=tmp;
return pieces;
}


char *Cexplode_getNth(int index,CexplodeStrings exp_obj)
{
if(exp_obj.amnt<index)
{
    return NULL;
}
return exp_obj.strings[index-1];
}

char *Cexplode_getfirst(CexplodeStrings exp_obj)
{
return Cexplode_getNth(1,exp_obj);
}
void Cexplode_free(CexplodeStrings exp_obj)
{
int i=0;
for(;i<exp_obj.amnt;i++)
    free(exp_obj.strings[i]);
free(exp_obj.strings);
}

Cexplode_example.c

/* ******************************************************** */
/*                                                          *
*      Implementation of php's explode written in C        *
*      Written by  Maz (2008)                              *
*      http://maz-programmersdiary.blogspot.com/           *
*                                                          *
*      You're free to use this piece of code.              *
*      You can also modify it freely, but if you           *
*      improve this, you must write the improved code      *
*      in comments at:                                     *
*      http://maz-programmersdiary.blogspot.com/           *
*      or at:                                              *
*      http://c-ohjelmoijanajatuksia.blogspot.com/         *
*      or mail the corrected version to me at              *
*      Mazziesaccount@gmail.com                            *
*                                                          *
*      Revision History:                                   *
*                                                          *
*      -v0.0.1 16.09.2008/Maz                              *
*                                                          */
/* ******************************************************** */

#include "stdio.h"
#include "Cexplode.h"

int main(int argc,char *argv[])
{
char *string;
char *delim;
int retval;
int index=0;
char *token;
CexplodeStrings expString;
if(argc!=3)
{
    printf("Test Command should be:\n");
    printf
    (
      "<testExe> \"original string\" \"delimiter string\""
    );
    return -1;
}
string=argv[1];
delim=argv[2];

printf("TestString is \"%s\"\n",string);
printf("Test Delimiter is \"%s\"\n",delim);
if(0>(retval=Cexplode(string,delim,&expString)))
{
    printf("CexplodeFailed!\n");
    return -1;
}
else
{
    //Way 1, use expString straight away:
    printf("Way 1, use expString straight away:\n");
    for(index=0;index<expString.amnt;index++)
    {
        printf
        (
          "token %d = %s\n",
          index+1,
          expString.strings[index]
        );
    }
    /*
       Way 2, you can use Cexplode_getNth,
       or Cexplode_getfirst()
    */
    printf(
     "Way 2 use Cexplode_getNth, or Cexplode_getfirst():\n"
    );
    token=Cexplode_getfirst(expString);
    printf("first token %s\n",token);
    index=1;
    while(NULL!=(token=Cexplode_getNth(++index,expString)))
    {
        printf("token %d = %s\n",index,token);
    }
}
Cexplode_free(expString);
return 0;
}

Monisäikeiset ohjelmat.

2008-09-10T19:06:00.005+03:00

olen jo aiemmin blogissani esitellyt pthread kirjaston käyttöä säikeiden luontiin. Mainitsin myös semaforien ja mutexien käytön, sekä näytin muutaman esimerkin syntaxista. Nyt tarkoituksenani on kertoa hieman enemmän aiheeseen liittyvistä sudenkuopista.

Re-entrancy ja thread safety:

Pohditaampa hetkinen monisäikeisten ohjelmien toimintaa, ja muuttujien näkyvyyttä. Monisäie ohjelmoinnissahan useampi koodinpätkä voi olla suorituksessa yhtä aikaa. Pohditaanpa hetkinen mitä tämä merkitsee funktiotasolla. Tehdään jälleen ongelman ytimen selkeyttävä ajatusleikki. Kuvitellaanpa että meillä on funktio, joka keittää kahvia. Kahvinkeitin olkoon muuttuja jota funktiomme käyttää. Nyt meillä on kaksi vaihtoehtoa sille, miten kahvinkeittimemme sijoitamme. Voimme luoda kahvinkeittimen funktion sisällä, jolloin joka kerta kun funktiota kutsutaan, luodaan uusi kahvinkeitin. Tai sitten voimme määritellä kahvinkeittimemme globaalina muuttujana, jolloin kahvinkeittimiä on vain yksi, ja aina kun funktiota kutsutaan käytetään samaa kahvinkeitintä. Mititäänpä nyt hetki monisäikeistä ohjelmaa, kumpikohan kahvinkeitinmalli toimisi paremmin?

Nyt tekisi miei sanoa, että globaali keitin, kukas hullu sitä kahvia niin paljon keittää, ettei yksi keitin riitä? Mutta kun palaamme takaisin ohjelmointiin, huomaamme, että mikäli meillä on vain yksi keitin, ja mikäli kahvinkeittofunktiotamme kutsutaan monesta säikeestä, saattaa eteen tulla tilanne, että säie yksi on juuri keskellä kahvinkeittofunktiota, kun scheduleri päättää antaa ajoaikaa säie 2:lle. Nyt säie kaksi menee kahvinkeittofunktioon, ja ...

Huomaattehan riskin? on mahdollista, että säie yksi oli juuri täyttänyt kahvinkeittimen vesisäiliön, kun säie kaksi pääsi ajoon. Nyt säie kaksi kaataa säiliöön lisää vettä, ja keitin tulvii yli (kumpikin säiehän käytti samaa keitintä). Säie kaksi lisää kahvin, painaa virtanappulaa ja kaataa kahvin kuppeihin. Säie 2 jatkaa muissa tehtävissä, kunnes scheduleri antaa taas ajoaikaa säikeelle 1. Nyt säie yksi muistaa täyttäneensä veden, lisää kahvin ja painaa virtanappulaa. Mutta koska säie kaksi kävi välissä käyttämässä keitintä, vesisäiliö on nyt tyhjä, ja keitin palaa tuhkaksi...

Mietitäänpä miten ongelma voidaan välttää. Yksi keino on käyttää funktion sisäistä kahvinkeitin muuttujaa, jolloin aina kun keittofunktiota kutsutaan, kutsuja saa ihka oman keittimen käyttöönsä. Mutta aina tämä ei ole järkevää. Joskus on tarpeen käpistellä samaa muuttujaa/oliota/tms. useasta threadista. Nyt vaihtoehtona on käyttää edellä esiteltyjä semaforeja/mutexeja. Eli laitetaan keitin lukolliseen huoneeseen, johon on vain yksi avain. Nyt kun säie yksi ryhtyy kahvinkeittopuuhiin, se menee huoneeseen sisälle, ottaa avaimen lukosta, ja lukitsee oven perässään. Mikäli scheduleri antaa kesken kahvinkeiton ajoaikaa säikeelle 2, ja mikäli säie kaksi koettaa ryhtyä kahvinkeittoon, se törmää lukittuun oveen ja joutuu odottelemaan vuoroaan kunnes säie yksi on keittänyt kahvinsa. Säie yksi saa taas ajoaikaa, keittää kahvin valmiiksi, poistuu huoneesta ja jättää mennessään avaimen lukkoon. Nyt säie kaksi pääsee kokkailemaan, lukiten oven huoneeseen mennessään...

re-entrant ja thread safe ovat termejä jotka kuvaavat jonkin funktion soveltuvuutta monisäikeiseen ohjelmointiin. Termeillä on kuitenkin perustavaa laatua oleva ero. ohjelmointi, ja varsinkin C kun ovat ihmeitä täynnä, tuo edellinen lukkoesimerkki ei olekkaan aivan vedenpitävä. Eli lukkoesimerkki on esimerkki thread safe funktiosta, mutta re-entrant se ei ole.

re-entrant termi vaatii nimittäin, että funktio täyttää myös kvanttimekaniikan mukanaan tuomat kummallisuudet... Tai jotain :D Eli re-entrant funktio on sellainen, joka toimii myös tilanteessa jossa säie hyppää kesken jonkin funktion suorituksen suorittamaan samaa funktiota. Eli kahvinkeittoesimerkissämme säie yksi kesken kahvinkeiton tunneloituisi lukitun oven väärälle puolelle, ja pyrkisi uudelleen keittämään kahvia. Tämähän ei toimisi sillä avainhan jäi kahvinkeittohuoneeseen. Sen sijaan paikallista kahvinkeitintä käyttämällä tämä toimisi. Nyt kun säie yksi hyppäisi uudelleen funktion alkuun, se loisi itsellleen uuden keittimen, keittelisi kahvin ja palaisi sitten jatkamaan keittelyä sillä toisella keittimellä...

Mikä C:ssä siis saa moisia kvanttimekaanisia ilmiöitä aikaan?

No perus C:ssä oikeastaan vain rekursiiviset funktiot (eli funktiot jotka kutsuvat itseään). Rekursiivista funktiota rakentaessa ohjelmoija kuitenkin yleensä tietää tilanteen, ja osaa automaattisesti ottaa tällaisen tilanteen huomioon. Mutta tutkitaanpa hieman vaikka posix rajapintaa. (posix = portaple operating system standardi, joka määrittelee usita C-kielen funktioita ja metodeita. Tyypillisiä posix standardin täyttäviä käyttöjärjestelmiä ovat mm. linux ja unix). Posix määrittelee signaalit, joiden voidaan ajatella olevan ohjelmallisia keskeytyksiä. Eli säie määrittää funktion, jonka se suorittaa mikäli tietyntyyppinen keskeytys tulee. Nyt välittömästi kun tällainen signaali generoidaan, säie jättää sen hetkiset tehtävänsä, ja hyppää suorittamaan keskeytyksen käsittely funktiotaan.

Jos nyt jatketaan kahvinkeitto linjoilla, ja mietitään tilanne jossa olemme rekisteröineet kahvinkeittofunktion jonkin tietyn signaalin käsittely funktioksi. Sitten ohjelmamme huomaa janoisen vieraan, ja nostaa signaalin, jolloin säikeemme jolle kahvinkeittokäsittely oli määrätty, hyppää suorittamaan kahvinkeittofunktiota. Kuinka ollakkaan, yht-äkkiä, kesken kahvin keittelyn, ohjelmamme huomaa uuden janoisen vieraan. Keskeytys generoidaan, ja kahvinkeittokäsittelijämme jättää ensimmäisen keittokerran kesken, ja hyppää uudelleen keittofunktion alkuun. Mikäli meillä nyt on semafori tai mutexi suojaamassa globaalia keitintämme, saamme aikaan deadlockin, sillä semafori/mutex on varattuna (ovi on lukittuna), mutta säie jonka tulisi avata mutex/semafori, odottaa nyt kahvinkeittofunktion alussa, lukon takana... Ts. pattitilanne.

Eli, re-entrancy on tietyssä mielessä tiukempi vaatimus kuin thread safety. Ja keskeytysfunktioiden kanssa TULEE olla tarkkana.

Eli summa summarum, ongelmakohtia säikeiden kanssa:

1. saman resurssin käpistely useasta säikeestä. (globaali data, static muuttujat)
2. Deadlock. (Jonkin resurssin odottelu, kun vapauttaja odottelee myös).

Ja vielä.... STANDARDIKIRJASTON MUUTTUJAT EIVÄT PÄÄSÄÄNTÖISESTI OLE REENTRANTTEJA! Eli keskeytysfunktioissa tulisi välttää standardikirjaston funktioiden käyttöä! Myöskään thread safety ei standardikirjaston funktioille ole tavanomaista! Esim malloc ja free on yleensä toteutettu siten, että ne käpistelevät jotain globaalia resurssia jossa pidetään kirjaa varatuista muistiblockeista! Kuitenkin useista standardikirjaston muuttujista on tehty reentrantit/threadsafet versiot, jotka on myös tyypillisesti nimetty _r() ( esim strtok_r(). )

... Lisää ehkä taas joskus :)

Avainsana static C:ssä.

2008-08-28T21:17:00.009+03:00

avainsana static on ehkä C:n (ja myös C++:n) huonoimmin suunniteltu ominaisuus. Ja kun puhutaan C:n huonoimmin suunnitellusta osasta, puhumme ehkä maailmankaikkeuden kaikkien ohjelmointikielien sekavimmasta avainsanasta :)

Syyt ovat edelliseen väittämään ovat hyvin yksinkertaisia. Ensinnäkin C:ssä ja C++:ssa static määrettä käytetään joissain määrin eri tavoin. (C++:ssa static sanalle tulee vielä pari uutta käyttötarkoitusta). Tämä on omiaan sekoittamnaan jo ennestään sekavan koodarin pään. Kun tähän vielä lisätään se, että C:ssä sanalla static on kaksi toisistaan näennäisesti täysin poikkeavaa käyttötarkoitusta, hiipii mieleen ajatus että kielen kehittäjien sanavarasto lienee ollut hieman vajaa... Ehkä olisi ollut syytä harkita kahden eri sanan käyttämistä...

No kieli on tehty jo ajat sitten, joten tilannetta on turha itkeä enää. Täytyy siis vain yrittää oppia. Katsotaan ensin yksinkertaisempi, mutta äärimmäisen käytännöllinen static:n käyttötarkoitus. Kaikessa kauneudessaan:

Laittamalla sana static globaalin muuttujan määrittelyn eteen, muuttujan näkyvyys rajoittuu tiedostoon jossa se on esitelty.
Samalla tavalla laitettaessa static määre funktion esittelyn eteen, saadaan funktion näkyvyys rajoitettua ainoastaan siihen tiedostoon, jossa se on toteutettu.

esim:

funktiot.h


extern int G_globaali1;
extern int G_globaali2;

funktiot.c


int G_globaali1=1;
static int G_globaali2=2;
static void funktio1();
void funktio2();

void funktio1()
{
    ...
}

void funktio2()
{
    ...
}

main.c


#include "funktiot.h"
int main()
{
    int x;
    x=G_globaali1;
    x=G_globaali2;
    funktio1();
    funktio2();
    return 0;
}

Ylläoleva esimerkki ei linkkantuisi, sillä funktio1():tä ja G_globaali2:ta ei löytyisi main.c tiedostossa. Voitte kokeilla tätä tekemällä esimerkin mukaiset tiedostot, ja laittamalla jonkinlaisen toteutuksen funktio1:lle ja funktio2:lle. gcc:llä homma onnistuu sitten komennolla


gcc -o testi main.c funktiot.c

Koettakaa sitten ottaa static sanat pois, ja kääntäkää uudestaan...

Miksi kukaan sitten haluaisi rajoittaa funktion/muuttujan näkyvyyttä tällä tavalla? Pohditaanpa hetki. Minä olen ollut töissä eräässä projektissa, jossa samaa mammuttimaisen suurta ohjelmistoa teki arviolta 200 henkeä. En edes tuntenut kaikkia, saati että olisin tuntenut kaikkien tekemien ohjelmistokomponenttien toteutuksen. Ja ajan oloon unohdin myös itse tekemieni koodien yksityiskohdat.

ohjelmisto pohjautui viestipohjaiseen reaaliaika käyttöjärjestelmään, ja vain arvata saattaa kuinka moni koodari toteutti toisistaan tietämättä esim. send_msg() viestin. Testikoodeja ohjelmaan oli satojatuhansia rivejä, ja yksittäisi testejä tuhansia. Sopii vain pohtia kuinka monta status tai G_status tai G_test_status globaalia koodeissa esiteltiin. Yksinkertainen keino välttää päällekkäiset määritykset oli käyttää juuri static avainsanaa.

No niin. Koska tämä näyttää ihan selkeältä ja järkevältä, niin on syytä sekoittaa pakkaa ettei totuus unohtuisi :) Eihän C:n näin helppoa kuulu olla, joten vedetään kehiin static sanan käyttö funktion sisäisten muuttujien esittelyssä. No nythän näkyvyyttä ei ole tarpeen rajoittaa, funktion sisäiset muuttujathan eivät muutenkaan näy funktion ulkopuolelle. Paikallisten muuttujien yhteydessä static tekeekin muuttujista "staattisia". Ts. ne ovat varattuna jo ohjelman käynnistyksestä lähtien, riippumatta siitä, tuleeko ohjelman suoritus koskaan kyseistä funktiota kutsumaan. Staattiset muuttujat myös säilyttävät arvonsa funktion kutsujen välissä.

Ja valoitetaan jälleen esimerkillä:


typedef enum ElaskurinToimintamoodi
{
    ElaskurinToimintamoodi_lisaa=0,
    ElaskurinToimintamoodi_vahenna,
    ElaskurinToimintamoodi_palauta
}ElaskurinToimintamoodi;

int main()
{
    while(laskuri(ElaskurinToimintamoodi_palauta)<10)
    {
        if(laskuri(ElaskurinToimintamoodi_lisaa)==0)
        {
            printf("virhe laskurissa");
            return -1;
        };
        if(laskuri(ElaskurinToimintamoodi_lisaa)==0)
        {
            printf("virhe laskurissa");
            return -1;
        };
        if(laskuri(ElaskurinToimintamoodi_vahenna)==0)
        {
            printf("virhe laskurissa");
            return -1;
        };
    }
    return 0;
}

int laskuri(ElaskurinToimintamoodi toiminto)
{
    static int luku=0;
    switch(toiminto)
    {
        case ElaskurinToimintamoodi_lisaa:
          luku++;
        break;
        caseElaskurinToimintamoodi_vahenna:
          luku--;
        break;
        case ElaskurinToimintamoodi_palauta:
          return luku;
        break;
        default:
            printf("Virhe! Tuntematon toimintamoodi annettu");
            return 0;
        break;
    }
}

Kuutioidaanpa hetki tuota laskuri funktiota. Eli funktiolle annetaan parametrina enumin arvo, joka kertoo mitä laskurin tahdotaan tekevän. Itsestään selvää. Mutta mitä mitä. Nythän laskurin arvo pidetään funktion sisäisessä muuttujassa "luku", eikä globaalissa. Normaalistihan tämä muuttuja menettäisi arvonsa aina kun funktiosta poistutaan. Tässä nyt kuitenkin arvo säilyy, avainsana static:in ansiosta. Pohditaanpa vielä hetki. lukuhan määritellään funktion alussa: static int luku=0; Miksei luku muuttujaan siis joka kutsulla talleteta nollaa, ja sekoiteta näin laskuriamme? Static sanan toinen merkillisyys on siinä, että static muuttuja alustetaan vain kerran, ohjelman suorituksen alkaessa. Koska muuttuja ei ikinä poistu muistista (ikinä on nyt siihen asti kuin ohjelman suoritus kestää, eli esimerkin tapauksessa, nykyajan koneilla muutamia millisekunteja. Suhteellisuusteoria on siis todistettu ajan suhteellisuuden osalta.)

Ja viimein. C++:ssa static:lla on siis lisäksi omat tarkoituksensa, ja siitä ehkä jokin toinen kerta...

php explode() ja rtrim() funktiot C++:aan ja C:hen.

2008-08-23T23:15:00.004+03:00

Kohta 30 vuotisen taipaleeni varrella olen ehtinyt puuhastella monenmoista. Muun muassa tehnyt virheitä php:llä, mistä todisteena on CWF Freeware. Php:ssä on paljon hienoja funktioita stringien käsittelyyn, ja noita kaipailin joskus C/C++ kielissäkin. No nuorena miehenä koodailin omat versioni noista. Ja vaikka ne on koodattu urani aamunkoitossa, eivätkä luultavasti ole parhaita mahdollisia toteutuksia, on ne kuitenkin toimivia. Ja ajattelin, että kun kerran minä noita kaipasin, niin miksein joku muukin. Joten tässä tulee:

explode() for C++:


#include <iostream>
#include <vector>
#include <string>

using std::string;
using std::vector;


int explode(string tear_me,string cut,vector &store)
{
        unsigned int start=0;
        int len=0;
        int i=0;
        vector<string> temp;

        len=cut.length();
        if(tear_me.find(cut)==string::npos)
        {
                return -1;
        }
        while( (start=tear_me.find(cut))!=string::npos)
        {
                temp.push_back(tear_me.substr(0,start));
                tear_me.erase(0,start+len);
                i++;
        }
        temp.push_back(tear_me);
        store=temp;
        return i;
}

rtrim() for C:


#include <string.h>

/**
\brief removes trailing whitespaces and tabs from a string.
\returns number of characters removed
*/
int trim(char *text)
{
    int i;
    int len;
    int retval=0;
    len=strlen(text);
    for
    (
      i=len-1;
      i>=0&&( text[i]==' ' || text[i]=='\t' );
      i--
    )
    {
        text[i]=(char)0;
        retval++;
    }
    return retval;
}

rtrim on kevennetty versio. Se poistaa vain tabulaattorit ja välilyönnit, mutta yhden argumentin lisäyksellä, ja for ehdon pienellä muokkauksella saavutettaisiin php rtrim():n koko toiminnallisuus. (eli mahdollisuus poistaa myös muita merkkejä).

C ja muisti osa 3 - Muistin varaaminen

2008-08-23T16:36:00.025+03:00

No niin. Ensimmäiset Segmentation Fault:it siis lienee aikaansaatu. Älkää pelätkö, mikäli harrastatte C-ohjelmointia jatkossakin, tulette näkemään tuon virheen vielä monen monta kertaa. Itse asiassa, kaikkein kokeneinkin ohjelmoija joutuu toisinaan nöyrtymään tuon ilmoituksen edessä...

Segmentation Fault kaikessa yksinkertaisuudessaan tarkoittaa, että ohjelmanne erehtyi käpistelemään jotain muistialuetta jonne sillä ei olisi ollut asiaa. Yksinkertainen tapa saada tämä aikaan, on kääntää ja ajaa vaikka seuraava koodipätkä:


int main()
{
  char *osoitin;
  strcpy
  (
    osoitin,
    "kaadu! Tama kirjoitetaan varaamattomaan muistilohkoon"
  );
  return 0;
}

Pohditaanpa jälleen hieman muistia ja käyttöjärjestelmää.

ohjelmaa ajettaessa käyttöjärjestelmä varaamaa sopivan köntin muistia ohjelmaan kirjoitetuille tavallisille muuttujille, tiedolle siitä mistä funktiosta mihinkin on hypätty jne. Tätä ennalta varattua muistikönttiä kutsutaan pinoksi, eli stackiksi. Pino on muistialue, joka pysyy varattuna ohjelman suorituksen ajan.

Mietitäänpä sitten hieman jotain todellista sovellusta, Esim. tekstieditoria. Nyt ohjelman käynnistyessä ei mitenkään voida tietää tarvittavan muistin määrää, sillä käyttäjän kirjoittamat merkit täytyy tallettaa muistiin siksi aikaa, kunnes käyttäjä tallettaa kirjoittamansa merkit tiedostoon. Miten tällaista ongelmaa lähestytään? Voisimme tietysti päättää, että editoriin sopii maksimissaan X merkkiä, ja varata tämän muistimäärän etukäteen. Tämä kuitenkin olisi kömpelöä, sillä se muodostaisi ylärajan editoitavan tekstin koolle, ja varaisi aina ohjelman käynnistyessä kyseisen määrän - ja koska yleensä käyttäjät kirjoittavat eri mittaisia tiedostoja, olisi suurimman tiedoston vaatima muisti paljon keskimääräisen tiedoston vaatimaa muistia suurempi. Ja kuitenkin joka kerran joutuisi editori käynnistyessään varaamaan muistia suurinta tiedostoa varten... Yksinkertaisesti sanottua, editori kuluttaisi muistia järjettömän paljon, melkein kuin M$:n sovellukset...

Ratkaisu on nk. dynaaminen muistinvaraus. Eli C-kieli mahdollistaa muistin varaamisen ajon aikana. Tämä dynaaminen varaus tehdään käyttämättömästä muistialueesta "keosta" (heap). Eli kun ohjelma tarvitsee lisää muistia, se pyytää käyttöjärjestelmää varaamaan tarvitsemansa tilan, ja saa paluuarvona varatun tilan alkuosoitteen.

Jatketaampa ajatusleikkiä. Kuvitellaan, että olemme tehneet webbiselaimen dynaamisen muistinvaraamisen avulla siten, että aina kun käyttäjä avaa sivuston, sivuston vaatima tila on dynaamisesti varattu. Kuvitellaan edelleen, että käyttäjä surffaa koko työpäivän netissä, aukoen ja sulkien sivuja... Tästä päästään toiseen erittäin tärkeään dynaamiseen muistinkäyttöön liittyvään asiaan, eli muistin vapauttamiseen.

Normaalit muuttujat jotka on otettu pinosta vapautetaan automaattisesti sen funktion suorituksen loputtua, jossa muuttuja on esitelty. (10 psiteen kysymys, mikä vaara piilee osoittimissa, jotka osoittavat näihin nk. lokaaleihin muuttujiin?) Sen sijaan dynaamisesti varattu muisti pysyy varattuna aina ohjelman suorituksen loppuun asti, ellei sitä erikseen vapauteta! Vapauttamatta jääneitä muistilohkoja kutsutaan muistivuodoiksi, ja ohjelmissa joita on suunniteltu suoritettavan pitkän aikaa, muistivuodot voivat olla todellinen riesa, aiheuttaen ajanoloon koko koneen hidastumista ohjelman rohmutessa lisää ja lisää muistia.

Mutta katsotaanpa nyt se C:n tyypillisin tapa varata muistia:


int main()
{
  int *luku;
  char *teksti;

  luku=(int *)malloc(sizeof(int));
  if(luku==NULL)
  {
    printf("Muistin varaaminen epaonnistui!");
    return -1;
  }
  *luku=5;
  //varataan tilaa sanalle viisi:
  //tarvitaan 6 charia, 5 kirjaimille ja yksi lopun '\0':lle
  teksti=(char *)malloc((5+1)*sizeof(char));
  if(teksti==NULL)
  {
    printf("Muistin varaaminen epaonnistui!");
    return -1;
  }
  strcpy(teksti,"viisi");
  printf("%d eli %s",*luku,teksti);
  //vapautetaan muisti
  free(teksti);
  free(luku);
  return 0;
}

Eli avainsanat muistin varaamiseen ja vapautukseen ovat malloc() ja free(). malloc() varaa muistia niin monta tavua kuin argumenttina annetaan. Eli argumenttina on annettava halutun tietotyypin koko. onnistuessaan muistinvarauksessa malloc palauttaa varatun muistialueen alkuosoitteen, joka talletetaan osoittimeen. Epäonnistuessaan malloc palauttaa NULL:in (eli 0 osoitteen). mallocin paluuarvo on aina syytä tarkistaa, sillä NULL osoitteen käpistely myöhemmin johtaa tuhoon ja hävitykseen...

free() funktio vapauttaa varatun muistin, mutta jättää osoittimen sojottamaan vapautettuun muistilohkoon. Luonnollisestikin vapautetun muistilohkon käyttö johtaa softan kaatumiseen, joten vapautuksen jälkeen osoitin on käyttökelvoton kunnes se jälleen laitetaan osoittamaan jotain järkevää. Ja viimeksi, myös vapautetun muistilohkon uudelleen vapautus johtaa ohjelman kippaamiseen, samoin kuin pinosta varatun muistipalan vapautus.

Ihan viho viimeksi mainitsen vielä [] operaattorin. Eli esittelemällä muuttujan muodossa:

tyyppi nimi[koko];

saamme muistialueen johon on varattu tilaa koko muuttujalle. Myöhemmin koodissa voimme käyttää [N] operaattoria päästäksemme käsiksi N:nteen taulukkoon talletettuun arvoon.


  int taulukko[10];
  int *osoitin;

  osoitin=(int *)malloc(10*sizeof(int));

Mikä edellä olevassa on osoittimen ja taulukon ero? Ero on se, että taulukko on nyt varattu stackista, ja sitä EI voi vapauttaa free() kutsulla, vaan se säilyy varattuna koko ohjelman suorituksen ajan. Ja tähän sopii vielä pieni huomautus sizeof() funktiosta, joka siis kertoo montako tavua tilaa jokin tyyppi/muuttuja vie muistista. sizeof() kuitenkin muutetaan luvuksi jo ohjelmaa käännettäessä, joten:


  int taulukko[10];
  int *osoitin;

  osoitin=(int *)malloc(10*sizeof(int));
  printf
  (
    "taulukko=%d osoitin=%d",
    sizeof(taulukko),
    sizeof(osoitin)
  );

tulostaa eri koot taulukolle ja osoittimelle. (taulukolle 10*4 eli 10 int:n viemän tilan ja osoittimelle arkkitehtuurista riippuen 4 tai 8, eli osoittimen vaatiman tilan). Ja viimeinen esimerkki siitä, miten [] operaattorilla accessoidaan tiettyyn muistipaikkaan:


  char taulukko[10];
  char *osoitin;

  osoitin=(int *)malloc(10*sizeof(int));
  strcpy(taulukko,"kymmenen!");
  strcpy(osoitin,"kymmenen!");
  osoitin[8]='?';
  taulukko[0]='x';
  printf("taulukko=%s osoitin=%s\n", taulukko, osoitin);

Tämä tulostaisi:
taulukko=xymmenen! osoitin=kymmenen?

Huomaa siis, että [] operaattoria käytettäessä, taulukon ensimmäinen arvo on 0, ja viimeinen on koko-1. Eli:


  char taulu[10];
  taulu[10]='\0';

kirjoittaa '\0':n taulukon ulkopuolelle!

EDIT:
Jäi vaivaamaan... Nimittäin unohdin mainita realloc() ja calloc() kutsut, jotka malloc():n lisäksi ovat erittäin käyttökelpoisia. Mutta koska kömmin jo sängystä tekemään tämän lisäyksen, en jaksa niistä enempää jaaritella. Kannattaa kuitenkin katsoa ne vaikka man sivuilta, vaikka tuota tällä sivulla olevaa man hakua käyttäen. (toivottavasti se toimii, en voi itse testata, koska se on samalla sellainen mainoshässäkkä, ja olen sitoutunut olemaan käyttämättä sitä :rolleyes:)
Ja nyt alkaa taas uni painaa, joten palataan jälleen joku toinen päivä :)

C ja muisti osa 2 - osoittimet eli pointterit.

2008-08-23T12:28:00.024+03:00

osa 1:ssä pohdittiin hieman muistia noin yleisesti, ja käytettiin osoittimia ihan sujuvasti. Koska aloittelevilla C koodareilla on usein ongelmia ymmärtää osoittimia eli pointtereita, ajattelin lisätä jo ennestään valtaisaan osoitin-tutoriaali tulvaan omani.

Eli kuten aiemmin kerroin, C-kielessä muistin käsittely on oikeastaan kaiken a ja o. Suora pääsy tiettyyn muistipaikkaan, jonne jotain dataa on jo talletettu mahdollistaa ylimääräisen kopioinnin välttämisen, eli siis nopeuttaa ohjelmaa ja vähentää muistin kulutusta. Samalla se kuitenkin on myös C-ohjelman haastavimpia asioita, ja virheelliset muistiaccessit aiheuttavatkin todella ikäviä ja vaikeasti paikannnettavissa olevia virheitä. Mutta eiköhän tässä nyt tullut pohjustusta tarpeeksi, menen siis seuraavaksi itse asiaan.

Eli kuten ykkösosassa totesin, käyttöjärjestelmä paloittelee muistin lohkoihin, jotka se numeroi. Eli varsinainen data (esim. muuttujan arvo) on aina talletettu johonkin tiettyyn lohkoon, jota edustaa lohkon numeerinen osoite. normaalia muuttujaa käytettäessä, koodarin ei tarvitse välittää osoitteesta, sillä kääntäjä piiloittaa osoitteen käytön. Tämä kuitenkin tarkoittaa sitä, että mikäli sama data halutaan tallettaa myös toiseen muuttujaan, on data kopioitava toiseen muistilohkoon johon kääntäjä liittää uuden muuttujan nimen.

Esim:


int muuttuja1;
int muuttuja2;

muuttuja1=1; //laitetaan arvo 1 muistiin johonkin lohkoon,
// jota edustaa nimi muuttuja1

muuttuja2=muuttuja1; //kopioidaan data toiseen muistilohkoon,
// jota edustaa nimi muuttuja2

Joskus olisi kätevää pystyä linkittämään nimi muuttuja2 samaan muistilohkoon johon nimi muuttuja1 on linkitetty. Tällöin muuttuja1:tä muutettaessa, myös muuttuja2:n arvo luonnollisesti muuttuu. (koska kumpikin osoittaa samaan dataan, ei toiseen muistilohkoon kopioituun dataan). Tämä on mahdollista pointtereiden avulla.

Pointteri on yksinkertaisuudessaan muuttuja, joka sisältää muistipaikan osoitteen. Lisäksi pointteri sisältää muistipaikkaan talletetun datan tyypin, jotta kääntäjä tietäisi miten monta tavua muistipaikasta on luettava, jotta saadaan selville data johon pointteri osoittaa. (osassa 1 totesimme, että C-kielen eri tietotyypit vaativat eri määrän tilaa.) Nyt tarkkana, näytän miten pointteri tehdään. Ja ikävä kyllä, jälleen syntaxissa on kohta, joka saattaa tuntua aloittelijasta sekavalta...


int muuttuja1;
int *muuttuja2;

muuttuja1=1;
muuttuja2=&muuttuja1;

Näyttää lähes samalta kuin edellinen esimerkki. Tarkkaavainen lukijani (eli et sinä Vesku, vaan Kari), huomaa, että erona on nyt * ja & merkkien käyttö.

otetaan helpompi ensin. Eli &-merkki. &-merkillä saadaan selville muuttujan (tai funktion) (alku)osoite. Toinen &-merkin käyttötarkoitus on bitwise and operaatio, mutta ei nyt vaivata päätämme sillä... Eli kun tahdomme käyttää muuttujan osoitetta johonkin, laitamme muuttujan nimen eteen &-merkin (C++:ssa & merkkiä voidaan myös käyttää funktion argumentin edessä, funktion prototyypissä, kun tahdomme... Äh. Antaa olla, tämä tuto koskekoon vain C:tä).

Sitten *. Nyt tarkkana. Äsken käytin *-merkkiä vain yhdessä kohdassa, mutta oikeasti sillä on kaksi osoittimiin liittyvää käyttötarkoitusta. Ensin kun esittelemme, eli luomme osoittimen, *-merkki kuuluu olla muuttujan nimen edessä, kertomassa että tahdomme muuttujan olevan osoitin. datatyyppi osoittimen edessä kertoo, minkä tyyppistä dataa muistipaikka johon osoittimen laitamme sojottamaan sisältää.

Tämän jälkeen kun tahdomme tallettaa osoitteita muistipaikkaan, emme käytä *-merkkiä. osoittimen esittelyn jälkeen, *-merkki kertoo, että tahdomme käpistellä DATAA joka muistipaikassa on. Esim:


int muuttuja1;
int *muuttuja2;

muuttuja1=1;
muuttuja2=&muuttuja1;
*muuttuja2=*muuttuja2+3;
printf("%d",muuttuja1);

Mitähän kyseinen funktio tulostaisi? Käydäämpä tämä tarkasti läpi.
Ensin luomme tavallisen muuttujan tyyppiä int.
Sitten luomme osoittimen nimeltä muuttuja2, ja kerromme, että se tulee osoittamaan int tyyppiseen dataan.
Talletamme muuttuja1:een arvon 1.
Sitten, oikealta vasemmalle luettuna:
otamme &-merkillä muuttuja1 sisältämän datan (eli luvun 1) osoitteen. Ts. Sen muistipaikan osoitteen, jossa muuttuja1:n sisältämä data on talletettuna. Talletamme tämän osoitteen muuttuja2:een, eli pointteriimme.
Sitten jälleen oikealta vasemmalle:
Lisäämme luvun 3, *muuttuja2:een. Eli siihen dataan joka on talletettu muistipaikkaan johon muuttuja2 osoittaa. olipa hankala lause, mutta kun luette sen 3-5 kertaa (Vesalla menee 5), sisäistätte kyllä asian. Nyt meillä siis on luku 1+3, eli 4. Tämän talletamme nyt *muuttuja2:een, eli siihen muistipaikkaan johon muuttuja2 osoittaa. Ts. muistipaikkaan jossa on muuttuja1:n arvo talletettuna. Nyt siis muuttuja1 onkin muuttunut 1:stä 4:ksi.
Ja niinpä viimeinen printf lause tulostaa näytölle numeron 4.

Huokaistaanpa nyt siis hetki, ja kuutioidaan mielessämme mihin tätä voi käyttää...

No niin. Funktio lienee toiselle teistä lukijani jo tuttu käsite. (En tarkoita sinua Vesa). Mietitäänpä hetkinen miten funktion parametrit välitetään funktion sisälle. Ihan oikein Kari, ne välitetään kopioimalla arvo uuteen muistipaikkaan, ja kertomalla tämä uusi muistipaikka funktion sisäiselle muuttujalle. Esim:



typedef struct kauheastidataa
{
int eka;
int toka;
int kolmas;
.
.
.
int sadasviideskymmeneskolmas;
}kauheastidataa;

int main()
{
 kauheastidataa dataa;
 dataa.eka=1;
 dataa.toka=2;
 dataa.kolmas=3;
 .
 .
 .
 dataa.sadasviideskymmeneskolmas=153;
 tulosta_data(dataa);
}

void tulosta_data(kauheastidataa data)
{
 printf
 (
     "eka=%d,
      toka=%d,
      ...,
      sadasviideskymmeneskolmas=%d",
      data.eka,
      data.toka,
      ...,
      data.sadasviideskymmeneskolmas
 );
}

Mitä edellinen esimerkki tekisi (siis jos se olisi loppuun asti kirjoitettu, eli ... paikat olisi asianmukaisesti täytetty, älä Vesa koeta kääntää sitä tuollaisenaan)?

Funktion kutsun kohdalla, koko kauheastidataa structi kopioitaisiin uuteen muistilohkoon. Tämä ei kuitenkaan olisi kovin järkevää, sillä kauheastidataa sisältää kauheastidataa, ja kun ohjelma turhaan kopioi kauheastidataa, se hidastuu tarpeettomasti, syö enemmän muistia, ja aiheuttaa pahennusta loppukäyttäjässä. Tämän kopioinnin välttämiseksi voisimme käyttää osoitinta alkuperäiseen kauheastidataa structiin, ja antaa siis tämän kauheastidataa structin muistiosoite tulostusfunktiolle. Tällöin ainoa mitä kopioidaan, on tuo kyseinen muistiosoite. Eli teemme seuraavasti:



typedef struct kauheastidataa
{
int eka;
int toka;
int kolmas;
.
.
.
int sadasviideskymmeneskolmas;
}kauheastidataa;

int main()
{
 kauheastidataa dataa;
 dataa.eka=1;
 dataa.toka=2;
 dataa.kolmas=3;
 .
 .
 .
 dataa.sadasviideskymmeneskolmas=153;
 tulosta_data(&dataa);
}

void tulosta_data(kauheastidataa *data)
{
 printf
 (
     "eka=%d,
      toka=%d,
      ...,
      sadasviideskymmeneskolmas=%d",
      *(data.eka),
      *(data.toka),
      ...,
      *(data.sadasviideskymmeneskolmas)
 );
}

Structit tarjoavat myös -> operaattorin, jota voidaan käyttää *(structi.jäsen) asemasta. Eli printtifunktion voisi kirjoittaa myös:


void tulosta_data(kauheastidataa *data)
{
 printf
 (
     "eka=%d,
      toka=%d,
      ...,
      sadasviideskymmeneskolmas=%d",
      data->eka,
      data->toka,
      ...,
      data->sadasviideskymmeneskolmas
 );
}

Ja vielä yksi maininnan arvoinen seikka.
oletko ikinä miettinyt miten merkkijonot talletetaan C-kielessä? (Kysymys ei koske sinua Vesa...). Mieti tarkasti, oletko ikinä nähnyt esim. seuraavaa:


char *merkkijono="merkkejä";
printf("%s", merkkijono);

Kun tuota tarkemmin tutkii, on merkkijonojen syvin olemus oikeastaan aika selvä. Eli itse asiassa C:n merkkijonojen käsittely tapahtuu luomalla osoitin char tietotyyppiin. Sitten C:n merkkijonoja käsittelevät funktiot on rakennettu niin, että ne aloittavat merkkijonon käsittelyn paikasta johon char osoitin osoittaa, ja olettavat merkkijonon jatkuvan kunnes kohtaavat merkin '\0' (eli (char)0, eli arvon 0x00) jossain muistipaikassa. Ts. merkkijonoja käsiteltäessä aletaan paikasta johon osoitin osoittaa, ja luetaan muistia eteenpäin 8-bitin eli yhden tavun palasissa, tulkiten jokainen luettu arvo merkiksi ASCII taulukon osoittamalla tavalla, kunnes törmätään tavuun, jossa kaikki 8 bittiä ovat nollia. Tässä siis piilee vaara. Kun käsittelet mekrrijonoja, varmista aina että viimeinen merkki on '\0'. Muuten tuloksena on .... jotain ei toivottua.

Ja nyt, mene kokeilemaan. Sitten kun linux koodarit saavat aikaan ensimmäisen kaatunisen virheilmoituksen "Segmentation Fault" kanssa, (ja windows koodarit muuten vaan crashin), tulkaa lukemaan seuraava pätkä muistin varaamisesta ;)
(Koetan kirjoitella senkin tämän viikonlopun aikana, tai viimeistään alkuviikolla).

Funktio-osoittimet C:ssä.

2008-08-07T21:17:00.009+03:00

Suurin osa C ohjelmijista törmää jossain uransa vaiheessa termiin "callback function", "jump tabl" tms. Hieman syvemmälle porauduttuaan, ohjelmoija huomaa, että ideana on tunkea funktio johonkin muuttujaan, josta sitä voidaan tarvittaessa kutsua.. Tai itse asiassa, eihän funktiota mihinkään laiteta, vaan osoitin funktion alkuun. Muistammehan toki, että ohjelma on vain köntti komentoja ja dataa muistissa. Ja jossain päin muistia majailee myös funktiot. Silloinhan on oikeastaan varsin luonnollista tallettaa funktion alkuosoite muuttujaan, ja tarvittaessa pompauttaa ohjelman suoritus tiettyyn kohtaan koodia, riippuen siitä, mikä funktio muuttujaan on talletettu...

No ihan näin helppoahan se ei kuitenkaan voi olla, eihän kyse muuten olisi C-kielestä.

ongelmaksi tulee taas tietysti C:n tietotyypit. osa funktioista voi syöda argumentteinaan chareja, osa inttejä, ja osa vaikka mitä... Joihinkin funktioihin ei mene parametreja, toisiin menee useita, ja paluuarvotkin vielä vaihtelee. Siksipä emme voikkaan tehdä "geneeristä" funktio-osoitin tyyppiä, joka kävisi kaikille funktioille, vaan erilaisia argumentteja/palautusarvoja käyttäville funktioille on määritettävä omat funktio-osoitin tyyppinsä. Ja tästä syystä mikäli teemme funktion, joka ottaa argumenttinaan funktiopointterin, on usein käytännöllistä määrittää argumentin tyypiksi "osoitin funktioon joka ottaa argumenttinaan void * osoittimen, ja palauttaa myös sellaisen". Tällöin emme sido liikaa funktiomme käyttäjän käsiä - varsinkaan jos emme tiedä tarkasti mihin tarkoitukseen funktiotamme tullaan käyttämään.

No niin. Mihinkäs tätä hienoutta nyt sitten voidaan käyttää? Ainakin kaksi asiaa tulee äkkiä mieleen. "Callbackit" ja "jump tablet".

Callbackit:

Kuvitellaanpa että teet C:llä hienonhienoa matopelimoottoria. Moottori laskee madon paikan ja huolehtii siitä, että käyttäjällä on mahdollisuus suorittaa haluamansa toiminto jos mato eksyy kielletylle alueelle eli seinään. Mutta koska et voi tietää millaista matopeliä käyttäjä onkaan tekemässä, et voi vain summanmutikassa piirtää traagista Game over ruutua. Varsinkaan kun et tiedä, tahdotaanko Game over ruudussa näkyvän verinen kolarin ajanut mato, vaiko kenties täysverinen kyy..

Yksi mahdollinen tapa tietysti olisi tehdä globaali muuttuja esim int G_matoSeinassa, joka olisi alustettu 0:ksi, ja madon kohdatessa seinän, moottori muuttaisi arvon ykköseksi.Nyt varsinaisen pelin pitäisi kuitenkin jatkuvasti 'pollailla' muuttujaa, nähdäkseen onko sen arvo muuttunut. Tämä luonnollisesti kuluttaisi turhaan arvokasta CPU-aikaa, ja koska käyttöjärjestelmät joiden päällä matopelejä pelataan ovat harvoin reaaliaika systeemeitä, tulisi seinään törmäyksen, ja muuttujaa pollailevan "taskin" suoritukseen mahdollisesti "lagia". Eli mato törmäisi ensin seinään, ja vasta tovin päästä peli huomaisi piirtää Game over ruudun - mahdollisesti päivitettyään ensin madon paikan seinän sisään..

Callback funktion käyttö on yksi mahdollinen ratkaisu ongelmaan. Eli, matopelimoottorin käyttäjä kirjoittelee funktion, joka hoitaa game over ruudun piirron, ja pysäyttää pelin muun etenemisen seinääntörmäyksen yhteydessä. Tätä funktiota nyt sitten käytetään "callback funktiona". Ts, annamme matopelikoneelle moottorin starttauksen yhteydessä osoittimen tähän funktioon, ja kerromme moottorille että mikäli mato kohtaa seinän, moottorin tulee kutsua kyseistä funktiota. Eli pelimoottoriin pitää siis koodata "callbackin rekisteröinti funktio". Yksinkertaisimmillaan se voisi olla seuraavanlainen temppu:


int rekisteroi_seina_callback( void (*seinaCBF)()   )
{
   //Tarkista ettei seinaCBF ole NULL
   if(NULL==seinaCBF)
       return 0;

/*
Talleta funktion osoite johonkin moottorin sisäiseen tietorakenteeseen myöhempää käyttöä varten
*/


   G_seinacallback=seinaCBF;
   return 1;
}

Ja kohta jossa seinäcallbackkia kutsutaan:


.
.
.
if( !mato_seinassa_checkki() )
{
   (*G_seinacallback)();
}

ja näin käyttäjä rekisteröisi seinäcallbackin:


void tee_tama_jos_seinassa()
{
.
.
.
}

void kaynnista_matomoottori()
{
   rekisteroi_seina_callback( &tee_tama_jos_seinassa );
}

Tai:


void kaynnista_matomoottori()
{
   void (*seinaCBF)() = &tee_tama_jos_seinassa;
   rekisteroi_seina_callback( seinaCBF );
}

Usein kannattaa kuitenkin käyttäjää ajatellen määritellä tarvittavaa funktio-osoitinta vastaava tyyppi, jolloin käyttäjän ei tarvitse käyttää C:n sekavia tietotyyppimäärityksiä vaan käyttäjä pystyy tekemään asiat definoidun tyypin nimellä. Eli:


typedef void (*seina_callback)()

int rekisteroi_seina_callback( seina_callback seinaCBF  )
{
   //Tarkista ettei seinaCBF ole NULL
   if(NULL==seinaCBF)
       return 0;

/*
Talleta funktion osoite johonkin moottorin sisäiseen tietorakenteeseen myöhempää käyttöä varten
*/


   G_seinacallback=seinaCBF;
   return 1;
}

Ja kohta jossa seinäcallbackkia kutsutaan:


.
.
.
if( !mato_seinassa_checkki() )
{
   (*G_seinacallback)();
}

ja näin käyttäjä rekisteröisi seinäcallbackin:


void tee_tama_jos_seinassa()
{
.
.
.
}

void kaynnista_matomoottori()
{
   rekisteroi_seina_callback( &tee_tama_jos_seinassa );
}

Tai:


void kaynnista_matomoottori()
{
   seina_callback seinaCBF = &tee_tama_jos_seinassa;
   rekisteroi_seina_callback( seinaCBF );
}

Eli tiivisteenä (sis 120% funktio-osoitin asiaa):

Funktio-osoittimen määrittely: (kts. C:n määrittelyjen luku)
parametriton, paluuarvoton funkti:

void (*nimi)();

arvon palauttava, parametrillinen funktio:

<paluuarvon> (*nimi)(<arg1>, <arg2>, ..., <argn>)

Eli esim.

double (*laske_summa_ptr)(double, double);

tai

void * (*varaa_muistia_ptr)(size_t maara);

Funktio-osoittimen alustus:


int *functio(char *foo, int bar)
{
}
...
int *(*osoitin_funktioon)(char *,int);
osoitin_funktioon = &funktio;

& - merkki voidaan useimpien kääntäjien kohdalla jättää pois funktion edestä, mutta portattavuuden takia se kannattaa varalta siinä pitää. Sitäpaitsi, kun kerran funktion osoite on se mitä oikeastikkin haetaan, on kauniimpaa käyttää &-operaattoria, jolla osoite oikeastikkin haetaan.
(osoitin_funktioon = funktio; /* tämä siis luultavasti toimisi myös, mutta on ruma ja laiska tapa jonka käyttäjät tulisi käristää hiljaisella tulella. */ )

funktio-osoittimen käyttö funktiota kutsuttaessa:

tulos = (*laske_summa)(1.00,1.00);

Ja jälleen on useimmilla kääntäjillä tuettuna myös kerettiläisyyden ruumiillistuma:
tulos = laske_summa (1.00,1.00);

Ja sitten, ihan vain virkistääksemme muistiamme edelliseen artikkeliin liittyen, katsomme yhden tyyppihirviön:


          int* (*(*foo)(int *,char *))(double,int *);

Eli, aletaan käymään läpi keskeltä, oikea -vasen - oikea (ellei kohdata sulkeita) systeemillä.
Siis: "Foo on.."
Sulkeet, eli vasemmalta => osoitin:
   "foo on osoitin..."
oikealle => funktio:
   "foo on osoitin
   ...funktioon..."
vasemmalle => osoitin,
   "foo on osoitin
   ...funktioon
   ...joka palauttaa osoittimen..."
oikealle => funktio
   "foo on osoitin
   ...funktioon
   ...joka palauttaa osoittimen
   ...funktioon..."
vasemmalle, oikealla ei enää mitään => osoitin ja int
   "foo on osoitin
   ...funktioon
   ...joka palauttaa osoittimen
   ...funktioon
   ...joka palauttaa osoittimen int tyypin lukuun"

... Toivotaan, että tuo meni oikein... Jompi kumpi teistä lukijoistani voisi varmaan tarkistaa tämän?

Ja sitten vielä se Jump Table

Ja ennen kun lopetan, kerron vielä lyhyesti mikä on hyppytaulu "jump table":

Eli, kuvitellaan tilanne, jossa meillä on funktio foo, joka palauttaa kokonaisluvun väliltä 0-5, siten, että palautetusta luvusta riippuen haluamme tehdä jonkin tempun. Mikäli temput ovat riittävän yksinkertaisia, eivätkä vaadi kovin paljoa informaatiota alkutilasta, saattaa olla if-else tai switch-case häkkyrää selkeämpi (ja tehokkaampi!) tapa käyttää "jump tablea".

Eli, luomme temppujen tekoon 5 eri funktiota. Kukin siis suorittaa yhden tempun. Pakotamme funktioille vielä samanlaiset argumentit.
Eli meillä on funktiot:


void temppu1(void);
void temppu2(void);
void temppu3(void);
void temppu4(void);
void temppu5(void);

Funktio josta saamme paluuarvon olkoot vaikka funktio


int mitas_seuraavaksi();

Nyt sitten jump table:


typedef void (*temppu_osoitin)(void);

void tee_temput()
{
   temppu_osoitin temput[5];
   temppu[0]=&temppu1;
   temppu[1]=&temppu2;
   temppu[2]=&temppu3;
   temppu[3]=&temppu4;
   temppu[4]=&temppu5;

/*
Nyt käytämme hyppytaulukkoamme. Vältämme siis funktion paluuarvon vertailun, mikä saattaa olla hyvinkin kriittinen ajansäästö jossain esim kiireellisissä loopissapyöritettävissä funktioissa DSP ympäristössä
*/


  *(temppu[ mitas_seuraavaksi()])();
}

Ja lopuksi huomautus kaikille veneilijöille, sekä muille lukijoilleni:
1. Esimerkit ovat jälleen kerran testaamatta, joten bugeja voi olla. Kiitän jokaisesta bugikorjauksesta jonka saan!
2. C++:n luokan jäsenfunktioille funktio-osoittimet ovat hieman erilaisia, mukana roudattavan this osoittimen takia..

Ehkäpä minun pitäisi seuraavaksi jaaritella C++ funktiopointtereista?
Ehkä, ehkä ei. Nyt on kuitenkin aika taas lopettaa, ja todeta että näemme ehkä ensi jaksossa taas, mitä se sitten pitääkään sisällään :)

C - kuinka luet tyypimäärittelyjä.

2008-08-05T21:45:00.005+03:00

C kielen tyyppimäärittelyt ovat usein hyvin kryptisiä, kun siirrytään perustyypien ulkopuolelle. Ei siis liene kummallista, että törmäsin kerran nettisivuun, jossa C-koodin hyvyyden mittayksiköksi kerrottiin koodikatselmoinnissa kuuluvien kommenttien esiintymistiheyttä, wtf/sec. ("Mitä v*ttua?" sekunnissa). (Nojoo, tämä pätee paljolti muuhunkin kuin tyyppimäärityksiin, mutta ei C:n sekavan näköiset tyypit ainakaan tilannetta helpota).

Tämän takia muistutankin teitä, että vaikka artikkelin luettuanne tiedättekin muistisäännön jonka avulla saa sekavistakin määrityksistä selkoa, niin typedefien käyttö on suotavaa... Kaikkihan eivät blogiani lue :)

Katsotaanpa ensin jokin sekavalta näyttävä määrittely:


    char *(*(*foo)[])(char *);

Mikähän olio mahtaa olla kyseessä? Paljastan sen artikkelin lopussa, mikäli et jo siihenmennessä onnistu itse sitä ratkaisemaan.

Yksinkertainen nyrkkisääntö on: Katso ensin oikealle, sitten vasta vasemmalle - ellei sitten sulkeet muuta järjestystä... Eli, aloitetaan aina kummajaisen nimen kohdalta (mikäli muuttujalle on annettu nimi, muuten pitää vain yrittää löytää sisin tietotyyppi...) Sen jälkeen katsotaan mitä on nimen oikealla puolella, sitten mitä vasemmalla, taas mitä oikealla... Paitsi jos sulkeet muuttavat järjestyksen... Kokeillaan:


    int foo;

Tapaushan on tietysti selviö, mutta ensin on hyvä koettaa että kikka toimii...

eli aletaan nimestä:
"foo on..."
Katsotaan oikealle - ei mitään. Katsotaan vasemmalle, "..int"
Eli: "foo on int".
YAY! Se toimi!

Uusi yritys:


   int *foo[1];

Aletaan nimestä:
"foo on.."
oikealle:
"foo on taulukko"
ja vasemmalle
"foo on taulukko joka sisältää osoittimen (mikäli koko olisi >1, "foo on taulukko joka sisältää osoittimia")
ja oikealla ei mitään, eli vasemmalle:
"foo on taulukko joka sisältää osoittimia intteihin"

YAY YAY! edelleen toimii!

Jatketaan...


   void **(*foo)[2]();

eli...
"foo on..."
nyt huomaamme sulkeet, joten katsomme sulkeiden sisälle ennen oikealle puolelle menemistä:
"foo on osoitin..."
sitten oikealle
"foo on osoitin taulukkoon..."
ja vasemmalle:
"foo on osoitin taulukkoon osoittimia..."
ja oikealle..
Nyt on edessä (). Tämä tarkoittaa tietysti funktiota. Eli:
"foo on osoitin taulukkoon osoittimia funktioihin..."
ja vasemmalle:
osoitin, oikealla ei muuta, vasemmalla vielä void
"foo on osoitin taulukkoon osoittimia funktioihin jotka palauttavat osoittimen 'voidiin'.", eli paremmalla suomella
"foo on osoitin taulukkoon osoittimia funktioihin jotka palauttavat void tyyppisen osoittimen."

Todella YAY!

Mutta pakko tunnustaa, että viimeisin tuntui jo aavistuksen epätoivoiselta... Katsotaanpa miten typedefeillä voitaisiin selkeyttää tilannetta:

typedef void *(*voidfunc)() //osoitin funktioon joka palauttaa void *:n
typedef voidfunk *osoitinvoidfunktioon //osoitin funktioon joka palauttaa void *:n

typedef osoitinvoidfunktioon taulukko_voidfunktio_osoittimia[2] //taulukko osoittimia void *:n palauttaviin funktioihin.
taulukko_voidfunktio_osoittimia *foo;

Ja jo pelkän ensimmäisen typedefin käyttö olisi selkeyttänyt tilannetta...


    voidfunk   *(*foo)[];

Ja nyt ratkaisu ensimmäiseen tyyppiin... Vastaus on:


char *(*(*foo)[])(char *);

"foo on osoitin taulukkoon osoittimia funktioon joka ottaa argumentiksi char osoittimen ja palauttaa osoittimen chariin".

Ja koska kello on taas liian paljon, en jaksa tarkistaa tätä tänään... Vaan painan pääni tyynyyn, nähden painajaisia huomisesta työpäivästä häröpointtereiden ja gummallisten castausten parissa...

Threadit eli säikeet.

2008-08-03T01:57:00.004+03:00

POSIX Threadit eli pthreads kirjasto

Kuten edellisessä blogipostissani mainitsin, threadit eli säikeet ovat keino ajaa useampaa kohtaa ohjelmakoodista yhden prosessin sisällä, näennäisesti yhtä aikaa. Yhdenaikaisuuden näennäisyys johtuu siitä, että mikäli koneessa on vain yksi (yksiytiminen) prosessori, ei se luonnollisestikaan voi tehdä kahta asiaa yhtä aikaa. Näennäinen yhdenaikaisuus saadaan aikaan käyttämällä ns. scheduleria, joka paloittelee koodin pienempiin suorituspätkiin, ja ajaa kutakin pätkää vuorollaan. Se mitä pätkää milloinkin ajetaan, ja kuinka paljon, riippuu schedulerin luonteesta. Muutamia yleisiä "hyvätietää pointteja" voin kuitenkin mainita.

Ensinnäkin, skedulereihin (ja käyttöjärjestelmiin) voidaan tehdä karkea jako, tavalliset käyttöjärjestelmät ja reaaliaika systeemit. Tavallinen käyttöjärjestelmä on "joustavampi". Mikäli teet esimerkiksi ajastimen, jonka tulisi laueta 2 millisekunnin välein, voit olla varma siitä että normaali käyttöjärjestelmä ei tähän kykene. Ja harvoin sen tarvitseekaan. Normaali käytössä tärkeää on muun muassa se, että kun käyttäjä painaa nappia, kone reagoi nopeasti. Eli korkeampi prioriteetti on I/o operaatioilla, ja scheduleri suosiikin I/o prosesseja. Lisäksi aina kun scheduleri vaihtaa toisen threadin (tai prosessin) ajoon, kuluttaa se ajoaikaa läpikäydessään omaa tehtävälistaansa ja hoitaessa muita sisäisiä asioitaan. Siksi kovin tiuhaan tehtävää vaihtava scheduleri hidastaa koneen kokonaistoimintaa. Reaaliaikasysteemit taas on kehitetty vastaamaan tarpeeseen saada ajastimet jne. mahdollisimman tarkoiksi. Ajatellaanpa esim auton tietokonetta, jonka tehtävänä on hoitaa luistonesto mekanismia lisäämällä/vähentämällä vääntöä pyöristä ajo-ominaisuuksien parantamiseksi. Muutaman millisekunnin epätarkkuus saattaisi jo kriittisessä tilanteessa saada auton lähtemään luisuun. Reaaliaikasysteemeissä scheduleri tyypillisesti vaihtaa suoritettavaa tehtävää huomattavasti useammin kuin normaalisysteemeissä. Mutta ennen kun unohdan koko kirjoitukseni alkuperäisen idean, on parasta vain todeta että schedulerit ovat mielenkiintoisia kikkuloita, ja niihin liittyy monia nerokkaita algoritmeja. Alkuun pääset vaikkapa hakemalla googlella tietoa round robinista.

mmm.. mistä aioinkaan kirjoittaa?

Ai niin, säikeistä. Yhdenaikainen ohjelmakoodin suoritus aiheuttaa omat ongelmansa. Se mahdollistaa kokonaisen joukon uusia mahdollisia bugeja tehtäväksi. Esim saman resurssin käpistely kahdesta eri säikeestä yhtä aikaa, on melko varma keino saada systeemi nurin...

Ah. Nyt tarkkaavainen lukijani (joo, taisit olla sinä Kari S., Vesa H. kun ei jaksanut näin pitkälle ;) ) on huomaavinaan aukon selvityksessäni. Aiemminhan minä totesin, että yhdenaikaisuus on näennäestä, prosessori kun tekee vain yhtä asiaa kerrallaan - miten siis samaa resurssia voitaisiin käpistellä yhtä aikaa? Kari hyvä, vaikka kerroinkin ettei prosessori tee kuin yhtä asiaa kerrallaan, niin yhtä C-kielen funktiota saattaa vastata useampi prosessorikohtainen komento. Ja moniprosessori ympäristössä asia mutkistuu entisestään. Sitäpaitsi oli syy mikä tahansa, niin jos teet testiohjelman jossa useampi säie käpistelee samaa osoitetta tiuhaan tahtiin, niin ennemmin tai myöhemmin napsahtaa...

Usein kuitenkin on tarpeen käyttää samaa resurssia useammasta säikeestä. Miten siis tehdä tämä turvallisesti? No onneksi tähän on myös keksitty ratkaisu. Semaforit, mutexit ja luku/kirjoitus lukot. Mutex on kuin lukko, johon on vain yksi avain. Ensin lukko luodaan ja alustetaan (avain jätetään lukkoon :D) Ts. tehdään 'pthread_mutex_t muuttuja' ja kutsutaan pthread_mutex_init funktiota. Tämän jälkeen kun jokin threadi haluaa käpistellä jotain yhteistä resurssia, se kutsuu lukitusfunktiota (vetää lukon kiinni ja ottaa avaimen mukaansa) pthread_mutex_lock. Nyt lukko on kiinni, ja mikäli jokin toinen säie kutsuu lukkofunktiota mutexin ollessa lukittuna, blokkaa lukkofunktio kutsuvan säikeen suorituksen kunnes aiemmin lukon sulkenut säie avaa sen pthread_mutex_unlock. Finally the mutex is destroyed with pthread_mutex_destroy.

Semaforit ovat kuten mutexitkin mutta tälläkertaa avaimia onkin yhden sijasta useampi.

Ja jälleen kerran kun keksittiin uusi hieno ratkaisu ongelmaan, aikaansaatiin myös uusi bugin mahdollisuus. Eli ole varovainen semaforien ja mutexien kanssa, puolihuolimattomalla käytöllä aikaansaadaan ikuinen odotustilanne, eli "deadlock". Deadlock siis on tilanne, missä kahdella (tai useammalla) säikeellä on jokin resurssi hallussaan jota toinen tarvitsee, ja molemmat ovat juuttuneena odottamaan että toinen luovuttaa resurssin toiselle.

No nyt koetan viimeinkin päästä itse asiaan, eli threadin luontiin ja lopetukseen. Uuden threadin luonti tapahtuu pthread_create() functiolla. pthread_create() funktiolle annetaan argumenttina osoitin funktioon josta uuden säikeen suoritus aloitetaan. Lisäksi pthread_createlle annetaan parametrina starttifunktiolle menevä void * tyypin argumentti. Uusi säie voidaan käynnistää joko"joinablena" tai "detachedina", mutta detach eli irroitus voidaan halutessa tehdä myös myöhemmin, kutsumalla pthread_detach funktiota. Mikäli säiettä ei irroiteta, se voidaan (ja se tulee) 'liittää' kutsuneeseen säikeeseen sen varaamien resurssien vapauttamiseksi ja säikeen palauttaman paluuarvon lukemiseksi. Liittäminen tehdään pthread_join kutsulla, ja se on blokkaava kutsu, eli se pysäyttää liittävän säikeen suorituksen siksi aikaa, kunnes liitettävä säie on lopettanut suorituksensa joko pthread_exit kutsulla, tai palaamalla starttifunktiosta. Irroitettua säiettä ei tarvitse (eikä voi) liittää resurssien vapauttamiseksi, eikä sen paluuarvoa voida tutkia.

Ja vielä ennen koodiesimerkkiä pieni varoituksen sana:

Kuten aiemmin mainitsin useista säikeistä koostuvassa ohjelmassa tulee olla tarkkana staattisten sekä globaalien resurssien kanssa. Myös jotkut standardikirjaston funktiot käyttävät allaolevissa toteutuksissaan näitä, eivätkä niinollen sovi monisäikeiseen ohjelmointiin ilman asianmukaista semafori/mutex suojausta! Monisäikeisiin ohjelmiin soveltuvista funktioista käytetään englanninkielistä nimitystä "reentrant". Kallisarvoinen ystävämme google osaa varmasti koostaa sinulle listaa näistä funktioista.

Mutta nyt esimerkin pariin.

Esimerkki 1 - Blokkaavien sokettien käyttö, ohjelmassa joka ei saa jäädä "jumiin".
HUoMAA: Esimerkkikoodia ei ole testattu!


#include <sys/socket.h>
#include <inet/arpa.h>
#include <pthread.h>
#include <stdio.h>

#define NUKKUAIKA 1
#define YHTEYS_HUKASSA -666

pthread_mutex_t data_lukko;
void *socketti_data;
size_t datan_koko;

int main(int argc, char *argv[])
{
   pthread_t thred;
   int paluuarvo;
   datan_koko=0;
   data=NULL;
   char ip[]="127.0.0.1";
.
.
.

/* Alusta mutex käyttöä varten */

   if(pthread_mutex_init(&data_lukko, NULL))
   {
       //virhekäsittely, mutexia ei voitu alustaa.
   }
   /*
     argumentit: starttifunktio, attribuutit,
     osoitin threadin kahvaan, starttifunktion
     argumentit.
   */
   if(
     pthread_create
     (
       &pollaile_sockettia,
       NULL, 
       &thred,
       (void *)ip
     )
   )
   {
     //virhekäsittely, threadin luonti epäonnistui.
   }

   sleep(NUKKUAIKA);
   while(1)
   {
     //suojaa globaalit muuttujat lukoilla!
     pthread_mutex_lock(&data_lukko);
     if(datan_koko!=0)
     {
       if(*(int *)data==YHTEYS_HUKASSA)
       {
         if( (paluuarvo=pthread_join(thred)) )
         {
           //virhekäsittely, tarkista virhe paluuarvosta
         }
         pthread_mutex_destroy(&data_lukko);
         return 0;
       }
       kasittele_sockettidata();
     }
     pthread_mutex_unlock(&data_lukko);
     tee_tuiki_tärkeä_tehtävää_joka_ei_odotaa_sockettia();
   }
}

void *pollaile_sockettia(void *argumentit)
{
  char *ip;
  int socketti;
  size_t luettu;
  char puskuri[RECV_MAX];

  ip=(char *)argumentit;
   .
   .
   .
/*
  Tässävaiheessa ohjelmaa socketti on luotu
  ja yhdistetty, ja odotellaan vastausta palvelimelta
  toisen säikeen hoitaen samalla tuiki tärkeää tehtävää...
*/
 while( 1)
 {
   luettu=recv(socketti,puskuri,RECV_MAX,0);
   if(luettu==0||luettu==-1)
   {
   pthread_mutex_lock(&data_lukko);
     data=(void *)YHTEYS_HUKASSA;
   pthread_mutex_unlock(&data_lukko);
     pthread_exit(0);
   }
   pthread_mutex_lock(&data_lukko);
   datan_koko=luettu;
   data=puskuri;
   pthread_mutex_unlock(&data_lukko);
   /*
     nuku hetki että naapurithread ehtii lukea datan,
     ennen uuden datan lukua socketista
   */
   sleep(NUKKUAIKA);
 }
}

Ja vielä viimeisenä huomautuksena:
käännettäessä gcc kääntäjällä threadeja käyttävää koodia, tule linkkausvaiheessa käyttää flagia -lpthread, eli ottaa mukaan pthread kirjasto.

C ja muisti, osa 1

2008-07-31T20:39:00.008+03:00

Tietokoneen prosessorin toiminta voidaan karkeast yksinkertaistaa kahteen osaan.

1. Muistavaruuden käsittely
2. Komentojen suorittaminen.

Kohta yksi voidaan jakaa lukuun ja kirjoitukseen. Komennot taas yleensä manipuloivat luettua dataa, ja kirjoittavat lopputuloksen johonkin muistiosoitteeseen. Muistin lukua käytetään myös luettaessa seuraava suoritettava komento muistista. Huomionarvoista on, että prosessori näkee myös kaikki laitteet, levyt, näytön, verkkokortin jne. vain tiettyinä muistiosoitteina.

Ohjelmointi on prosessorille annettavien komentojen (ja ohjelmaan liittyvän datan) kirjoittamista muistiin, josta prosessori ne lukee ohjelmaa ajettaessa. Mikäli ohjelmointi tulisi tehdä suoraan kirjoittamalla prosessorin käskyt ja data sellaisenaan, olisi "hello word" ohjelman tekokin jo varsin haastavaa, ja vaatisi valtavaa tietämystä koneesta rautatasolla.

Sen vuoksi on kehitetty erilaisia ohjelmointikieliä, joissa yksinkertaisilla käskyillä suoritetaan useampi prosessorikomento halutun toiminnallisuuden saavuttamiseksi. Lisäksi käyttöjärjestelmä ja laiteajurit peittävät suuren osan alla olevan raudan erityispiirteistä, tarjoten omat (enemmän tai vähemmän) standardoidut keinonsa varsinaisiin laitteisiin käsiksipääsyyn.

C-kieli on kuitenkin niin sanottu 'matalan tason kieli', mikä tarkoittaa sitä, että vaikka monia asioita on huomattavasti yksinkertaistettu, niin edelleen ollaan kuitenkin varsin lähellä rautatasoa ja prosessorikäskyjä. Tästä seuraa se, että vaikka voit tuottaa ihan toimivaa ohjelmakoodia ymmärtämättä käyttöjärjestelmää/rautatasoa sen paremmin, niin voidaksesi todella ymmärtää miksi jokin toimii kuten toimii, tai voidaksesi todella luoda omaa koodia nauttien kaikista C:n tarjoamista mahdollisuuksista, sinun on tunnettava alusta jolle ohjelmaa kirjoitat.

Ehkäpä kaikkein eniten ongelmia C:n kirjoituksessa tulee muistinhallinnan kanssa. Tähän liittyy muutamia perusasioita, joita aion läpikäydä tässä blogitekstissäni:

Fyysinen muisti on käyttöjärjestelmän toimesta jaettu pieniin palasiin, ja palaset on numeroitu muistiosoitteiksi. Kuhunkin muistiosoitteeseen mahtuu 8 bittiä tietoa, eli yksi tavu.

C-kielen eri tietotyypeillä on oma pituutensa, tavanomaisimpien tietotyyppien ollessa:
int 32 bittiä, eli 4 tavua.
short int 16 bittiä, eli 2 tavua
char 8 bittiä, eli yksi tavu.
C:ssä voidaan käyttää myös tietotyyppä void, jonka pituutta ei ole määritetty.

Tietotyyppien pituuden selvittämiseksi, C:n standardi määrittä sizeof() lauseen. sizeof(int) palauttaa int tietotyypin koon, sizeof(short int) palauttaa short int:n koon jne.

Huom 1.
sizeof(char *) == sizeof(int *) == sizeof(void *) jne. sizeof( *) palauttaa osoitteen vaatiman tilan, ei sen datan jota osoitteesta alkavaan muistiin on talletettu.
HUOM 2!!! Osoitteen vaatima tila riippuu tietokoneen arkkitehtuurista, tyypillisesti 32 bittisissä koneissa, osoite on 32 bittiä leveä, mutta 64 bittisissä koneissa 64 bittiä leveä. Siis mikäli tahdotte kirjoittaa ohjelmakoodia, joka toimii molemmissa arkkitehtuureissa, älkää muuntako osoitteita int:tyypiksi, sillä 64 bittisessä arkkitehtuurissa osoite ei sovi int tyyppiin, vaan puolet osoitteesta leikkaantuu pois!

Tämän asian sisäistäminen ja ymmärtäminen on eräs C-ohjelmoinnin kulmakiviä. Vaikka muuttujatyyppiä käytettäessä, kääntäjä osaa itse hoitaa ohjelmakoodin sellaiseksi, että prosessori tietää montako tavua milloinkin on luettava, niin joskus on tarpeen 'kadottaa' tietotyyppi ja palauttaa data myöhemmin takaisin samaksi tyypiksi. Esittelen nyt muutaman tilanteen missä tällaista kikkailua voi joutua harrastamaan.

Joissain tilanteissa voidaan haluta luoda esim. funktio, jolle voidaan antaa erilaista dataa argumenttina, tilanteesta riippuen. Hyvänä esimerkkinä vaikka pthread kirjasto ja threadin luonti. (Thread eli säie on itsenäinen suorituspolku prosessin sisällä. Eli threadien avulla voidaan haarauttaa ohjelman suoritus suorittamaan useampaa koodia näennäisesti yhtäaikaa.)

Threadi luodaan kutsumalla pthread_create() funktiota, jolle annetaan parametrina sen funktion osoite, josta uuden säikeen suorituksen tahdotaan jatkuvan. Lisäksi annetaan uuden säikeen alkamisfunktion parametrit. pthread_create funktio on toteutettu siten, että se hyväksyy starttifunktioksi vain funktion, jonka argumentti on tyyppiä void *. Eli 'tyypittömän' datablockin osoite. Syy tällaisen argumentin käyttöön on yksinkertainen. pthread kirjaston tekijät, eivät voi tietää mihin tarkoitukseen kirjaston käyttäjät tahtovat uuden säikeen luoda. Täten on mahdotonta myöskään arvata, millaisia ja minkä tyyppisiä argumentteja starttifunktiolle voidaan antaa.

Otetaanpa esimerkki. Kuvitellaan, että olemme tekemässä webbiserveriä, jossa käytämme socketteja ihka ensimmäisen blogipostini esimerkin tapaisesti. Kohdassa jossa serverimme hyväksyy kuuntelevaan sockettiin tulevan yhteyden, serverin pitää päästä jatkamaan kuuntelua mahdollisimman nopeasti, jotta muut palvelimemme sisällöstä kiinnostuneet pääsevät katselemaan tarjoamaamme laatupornoa. Kuitenkin ensimmäisen clientin pyynnöt on käsiteltävä.

ratkaisemme ongelman käyttämällä threadeja. Kun hyväksymme uuden yhteyden, luomme uuden threadin joka aloittaa suorituksensa kasittele_clientin_pyynnot() funktiosta. Samalla annamme alkuperäisen kuuntelijasockettimme palata accept funktioon odottelemaan uusia yhteyspyyntöjä.

Mitä tietoja kasittele_client_request() funktiomme nyt tarvitsee? Ainakin socketin, jonka kautta clientin kanssa keskustellaan. Lisäksi clientin osoitetiedot on hyvä saada, jotta saadaan ne logitiedostoon talteen. Luultavasti täysiverisessä serverissä tarvittaisiin muutakin dataa, mutta tämän kohdan toteutuskin voisi olla hieman toisenlainen :)

Mutta kuinka nyt saamme socketin ja clientin tiedot kasittele_clientin_pyynnot() funktiolle? Argumentti jonka annamme on siis muistipaikan osoite. Helpoin mieleentuleva tieto on, sijoittaa socket ja osoitetiedot peräkkäisiin paikkoihin muistissa, ja antaa kasittele_clientin_pyynnot() funktiolle sen muistipaikan alkuosoite, josta datamme alkaa.

Esimerkki 1: Sekalaisen datan sijoittaminen peräkkäisiin muistipaikkoihin.


int sock;
struct sockaddr clientin_osoite;

void *socketti_ja_osoite; //muisti paikka josta data alkaa

.
.
.

/*
  Allocoidaan, eli varataan muistia sockettia ja osoitetta
  varten, niiden tarvitsema määrä. Malloc() palauttaa 
  paluuarvonaan osoitteen,josta varattu tila alkaa:
*/
socketti_ja_osoite=malloc(sizeof(int)+sizeof(struct sockaddr));
/*
  Tarkistetaan että muistn varaus onnistui, varaaminen voi
  epäonnistua mm. jos muistia ei ole vapaana
*/
if(NULL==socketti_ja_osoite)
{
  //virhekäsittely, muistin varaaminen epäonnistui!
}
/*
  Nyt kun muisti on varattu käytettäväksi, täytyy data saada 
  sijoitettua muistiin. Talletetaan ensin socketin numero 
  muistipaikan alkuun. Tehdään tämä memcpy eli muistin
  kopiointi funktiolla, joka kopioi 1. argumentin osoittamaan
  muistipaikkaan dataa, 2. argumentin osoittamasta
  muistipaikasta,
  3. argumentin kertoman tavumäärän. huom, & merkillä saadaan 
  minkä tahansa muuttujan muistipaikan alkuosoite.
*/
memcpy
(
    socketti_ja_osoite, //1. arg, eli mihin kopioidaan.
    (void *)&sock,      //2. arg, eli mistä kopioidaan.
     sizeof(int)        //3. arg, eli montako tavua kopioidaan.
);

/*
  Seuraavaksi meidän tulisi saada kopioitua clientin
  osoitetiedot sockettitiedon perään. Eli koska int tyypin
  tieto vaatii muistia 4 tavua, on osoite johon clientin
  tiedot tahdomme socketti_ja_osoite muistipaikka + 4 tavua.
  HUOMAA: Kun muistipaikkaan lisätään luku, lisää kääntäjä
  itse muistipaikan osoitteeseen niin monta pykälää, kuin on
  tarpeen että 
  LUVUN OSOITTAMA MÄÄRÄ OSOITTEESEEN YHDISTETTYÄ TIETOTYYPPIÄ
  VAATII.
  Tämän vuoksi 
  VOID * TYYPPISEEN OSOITTEESEE EI VOI LISÄTÄ MITÄÄN!
  Siksi joudumme muuntamaan (castaamaan) socketti_ja_osoite
  muistipaikan toisen tyyppiseksi.

  Selvennykseksi: Jos meillä on:
  void *foo=0x0,
  niin
  (char *)foo+4 on 4
  (int *)foo+4 on 4*4 eli 16.

  Siksi epäselvyyksien välttämiseksi minä itse muunnan aina
  osoitteeseen lisätessäni/siitä vähentäessäni osoitteen
  (char *) tyyppiseksi ja lisään sizeof( lisättävä tyyppi )
  koon. Mikäli
  tahdon lisätä useamman kuin yhden kappaleen jotain tietoa, 
  kerron sizeof() lausekkeen lukumäärällä.
  VARO KUITENKIN TÄTÄ, mikäli kappalemäärä ei ole tiedossa,
  sillä suurella kappalemäärällä voi sizeof()*kappalemäärä
  kasvaa suuremmaksi kuin 32 bitin kenttään sopii, ja
  sizeof*kappalemäärä voi 'pyörähtää ympäri' aikaansaaden
  hyvin pienen luvun. Erityisen ikävää tämä on muistia
  varattaessa jolloin varausfunktio ei näe virhettä, ja
  luulee muistin varaamisen sujuneen ongelmitta. Varatun
  muistin koko ei kuitenkaan nyt ole haluttu, ja ohjelma
  luultavasti kaatuu myöhemmin, ja jossain aivan muussa
  kohdassa kuin muistinvarauksessa jossa todellinen vika on.

  Oho. Eksyin sivuraiteille, mutta mennäänpä nyt resinalla 
  takaisin pääradalle.
*/
memcpy
(
    (void *)((char *)socketti_ja_osoite)+sizeof(int),
    (void *)&clientin_osoite,
    sizeof(struct sockaddr)
};
/*
  Tai vaihtoehtoisesti:
  memcpy
  (
    (void *)((char *)socketti_ja_osoite)+4,
    (void *)&clientin_osoite,
    sizeof(struct sockaddr)
  );
*/
/*
  Tai vaihtoehtoisesti:
  memcpy
  (
    (void *)((int *)socketti_ja_osoite)[1],
    (void *)&clientin_osoite,
    sizeof(struct sockaddr)
  );
 
*/
/*
  Tai vaihtoehtoisesti:
  memcpy
  (
    (void *)((int *)socketti_ja_osoite)+1,
    (void *)&clientin_osoite,
    sizeof(struct sockaddr)
  );
 
*/

/*
   Ja voila, data on nyt socketti_ja_osoite osoittaman
   muistipaikan perässä, valmiina pthread_create funktiolle
   annettavaksi.
*/

Esimerkki 2: Sekalaisen datan saaminen peräkkäisistä muistipaikoista.

Nyt rakennamme kasittele_clientin_pyynnot() funktioomme tarvittavat kikkulat, jotta saamme socketin ja clientin tiedot kaivettua argumentin osoittamasta muistialueesta. Vaikeutena on se, että koska tiedot annettiin funktiota kutsuttaessa void * tyyppisenä, ei funktion sisällä ole kääntäjän toimesta mitään tyyppitietoatietoa, eikä näinollen myöskään tietoa siitä, miten pitkä muistialue on kyseessä, onko se varattu käyttöä varten, tai miten monta tietorakennetta se sisältää. Ennen kuin tietoa voidaan käyttää, on tämä kaikki kerrottava kääntäjälle tavalla tai toisella.

Tähän on ainakin kaksi mahdollista lähestymistapaa. Joko luoda oikean tyyppiset muuttujat joihin tieto kaivetaan argumentista, tai laskea aina oikea muistipaikan osoite ja kertoa kääntäjälle datan tyyppi sen jälkeen.

Ensimmäinen tapa on mielestäni selkeämpi, helpompi käyttää ja koodia tutkivan työkaverin selkeämpi käsittää.


void * kasittele_clientin_pyynnot( void *sockettiJaOsoite)
{
  /*
    Luodaan siis muuttujat joihin socketti ja osoite
    talletetaan
  */
  int sock;
  struct sockaddr clientin_tiedot;

/*
  Minulla on tapana asettaa pointterit jotka eivät enää ole
  käytössä NULL:iksi, eli osoittamaan osoitetta 0. Tämä
  usein auttaa virheiden kiinnisaamisessa. Tarkistetaan
  siis onko argumenttina annettu osoite validi:
*/
  if(sockettiJaOsoite==NULL)
  {
    /*
      Virhekäsittely, socketti ja clientin osoitetieto ei
      ole oikein annettu.
    */
  }
  /*
    socketti on helppo, sillä sen arvo on heti muistin
    osoittmassa paikassa, ja perustyypin ollessa kyseessä
    voimme olla varmoja että sijoitusoperaattori on
    käytössä. Eli valehtelemme siis silmät kirkkaina
    argumentin tietotyypin olevan int *, eli osoite jossa
    on int tyypin tieto talletettuna. Sitten kerromme 
    kääntäjälle haluavamme datan tästä osoitteesta, ja
    tallennamme sen int tyypin muuttujaan.

    Huomaa, kun osoitemuuttuja luodaan, se tapahtuu:
    int *muuttujannimi;
    Näin se myös esitellään funktion prototyypissä. Mutta
    mikäli myöhemmin sijoitamme tähden osoitemuuttujan
    nimen eteen, se tarkoittaa että haluamme datan joka on
    osoitemuuttujan kertomassa muistipaikassa.

    Eli
    int *foo;  //luo osoitinmuuttujan int tyyppiseen dataan
    int bar;
    *foo=1;  //tallettaa luvun 1, foo:n osoitepaikkaan.
    /* 
      tallettaa bar muuttujaan osoitteessa foo olevan DATAN.
      Ei foon osoitetta.
    */
    bar=*foo; 
    sock=*((int *)sockettiJaOsoite);
      /*
        (int *)sockettiJaOsoite    => väitetään
        socettiJaOsoite kertoman muistipaikan sisältävän
        int tyyppisen datan.
        *((int *)sockettiJaOsoite) => Kerrotaan olevamme
        kiinnostuneita datasta, ei osoitteesta.
      */
    /*
      clientin tiedot saadaan ehkä helpoiten käyttämällä
      jälleen & merkkiä saadaksemme clientin_tiedot muuttujan
      muistipaikan osoitteen, ja  kopioimalla sinne
      sizeof(struct sockaddr) verran dataa sockettiJaOsoite+4
      muistipaikasta alkaen.
    */
    memcpy
    (
        (void *)&clientin_tiedot,
        (void *)(char *)sockettiJaOsoite+sizeof(int),
        sizeof(struct sockaddr)
    );
}

Jaha, mutta koska ilta alkaa taas hiipimään nurkkiin, taidan lopettaa tältä päivää ja jättä loput mehevät muistijutut ensi kertaan :)

Socketit - tapa välittää tietoa.

2008-07-28T21:22:00.043+03:00

C suomeksi...

C ja C++ kieli ovat jo suhteellisen ikääntyneitä, mutta edelleen elinvoimaisia ja tehokkaita ohjelmointikieliä. Jostain syystä suomekielistä dokumentaatiota on kuitenkin aika niukasti. Tähän blogiin on tarkoitus kirjoitella simppeleitä pätkiä sieltä täältä C:n laajasta valikoimasta. Tarkoituksena ei ole kirjoittaa kaikenkattavaa C-kielen opasta, vaan poimia kiinnostavia ja hyödyllisiä palasia ja antaa niistä riittävä tieto jotta kiinnostunut suomalainen koodarinalku pääsee liikkeelle.

Ohjelmoija joutuu usein tilanteeseen, jossa hänen on saatava tieto kulkemaan prosessilta toiselle, tai jopa tietokoneelta toiselle. Socketit on yksi mahdollisuus.

Miksi socketit?

Samalla koneella pyörivien prosessien väliseen tiedonjakoon löytyy muitakin keinoja, kuten putket, jaettu muisti, tiedostot jne. Kaikissa näissä on omat hyvät ja huonot puolensa. Jaettu muisti on nopea keino, putket ovat yksinkertaisia ja suhteellisen nopeita, tiedostot säilyttävät datansa ohjelman suorituksen päätyttyä...

Sockettien vahvuus on suunnittelun vapaus. Socketteja käyttämällä voidaan tarvittaessa siirtää kahdesta keskenään keskustelevasta prosessista toinen kokonaan eri koneelle, varsin pienin muutoksin. Lisäksi siinä missä esim putket ovat varsinaisesti Linux/Unix maailmaan kuuluvia, ja jaetun muistin käyttäminenkin tapahtuu eri käyttöjärjestelmissä eri tavoin, socket rajapinta löytyy kaikista POSIX ympäristöistä, ja windowskin tarjoaa oman winsock kirjastonsa joka eroaa POSIX socketeista vain muutamissa kohdissa. Niinpä sockettien avulla, pienellä etukäteistutustumisella on varsin mahdollista tehdä "portattavaa" softaa.

Ennen esimerkin pariin siirtymistä, mainitsen vielä, että socketteja voi käyttää eri verkkoprotokollien kanssa. Socketit tarjoavat mahdollisuuden lähettää dataa UDP:n, TCP/IP:n ja muutamien muiden protokollien kautta (UNIX maailmassa on mainittava samalla koneella ajettavien prosessien väliseen kommunikointiin tarkoitetut UNIX socketit, jotka ovat erinomainen vaihtoehto harkittaessa miten prosessien välinen kommunikointi tulisi hoitaa). Ja valitusta protokollasta huolimatta, varsinainen datan lähetys/vastaanotto on tehty varsin samanlaiseksi, käyttäjän tarvitsee vain huolehtia oikeantyyppisen protokollan määrittämisestä, ja mahdollisen yhteyden luonnista.

(TCP/IP on niin kutsuttu 'connected' protokolla, eli protokolla pitää vatsaanottajan ja lähettäjän välillä "yhteyttä auki", Ts. yhteyden muodostus, ylläpito ja lopettaminen tapahtuvat lähettämällä tietynlaisia ennaltasovittuja paketteja. Mutta sockettien käyttäjän ei tarvitse näistä murehtia, alla olevat kerrokset [IP-pinkka] huolehtivat siitä).

Koetan käydä läpi yksinkertaisen esimerkin (UNIX) socketien käytöstä. Käytän yksinkertaisuuden vuoksi "blokkaavia" funktioita (Ts. funktioita jotka pysäyttävät ohjelmakoodin ajon siksi aikaa kun odottavat socketin lukemisen/sockettiin kirjoittamisen olevan mahdollista). Ihan lopuksi saatan käydä läpi esimerkin select() funktion käytöstä, tutkittaessa onko uutta dataa saatavilla. HUOM: Windows ja UNIX maailmassa select() funktiossa on pieniä eroja. Windowsissa select():iä voi käyttää vain sockettien kanssa, tutkittaessa socketin tilaa. UNIX maailma ei erittele socketia muista 'file descriptoreista', ja select() funktiota voidaankin UNIX koneissa käyttää myös esim. tiedostojen tilan tutkimiseen.

HUOM! Esimerkkikoodeja ei taata bugittomiksi, koetan toki parhaani mukaan varmistaa, että koodit kääntyvät, ja toimivat, mutta kaikenkarvaiset pikku (ja isommat) bugit ovat toki mahdollisia. Tarkoitus tosin olikin esitellä vain perusperiaatteet, mutta kunhan saan aikaiseksi, koetan kääntää ja ajaa esimerkit ja korjailla pahimmat mokat :)

Esimerkki 1: TCP/IP Datayhteyden muodostus "kuuntelevaan" koneeseen(Client program)

#include <sys/socket.h> //otsikkotiedosto jossa esitellään socket ohjelmoinnissa tarpeellisia tietotyyppejä ja funktioita.
#include <unistd.h> //yleishyödyllinen kirjasto
#include <stdio.h> //perus I/O toiminnot
#include <stdlib.h> //malloc
#include <arpa/inet.h> //verkkoliikenne matskua
#include <string.h> //memcpy


int main()
{
    int sock; //socketti kahva; vertaa tiedoston avaaminen => kahva
    struct sockaddr_in osoite = {0};
    void *lahetettava_data;
    int luettu_koko;
    unsigned short int serverin_portti=12345;
    void *luettu_data;
    int datan_koko;
    char lahteva_sanoma[]="fooooo";
    int luvun_paluuarvo;

/*
  aseta socketin "perhe" AF_INET:iksi (connections using ethernet), 
  tyyppi SOCK_STREAM:iksi (stream soketti, ei paketti data SOCK_DGRAM
  kuten UDP:ssä), protocolla TCP:ksi ja luo socketti.
*/
    if( (sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) ) < 0 )
    {
      //virhekäsittely, socketin luonti epäonnistui
    }
/*
  Täytä vastaanottajan tiedot, kuten portti ja IP sekä sockettisi 
  perhe sockaddr_in tyyppiseen structiin.
*/
    osoite.sin_family      = AF_INET;
/*
  inet_addr() funktio muuttaa osoitteen struktiin sopivaan binary 
  muotoon, ja kääntää bittijärjestyksen "network byte orderiin"
  (Eniten merkitsevä tavu ensin. Normaalissa PC arkkitehtuurissahan
  käytetään Ns. "Little endian" arkkitehtuuria, missä eniten 
  merkitsevät tavut tulevat viimeisenä.
*/
    osoite.sin_addr.s_addr = inet_addr("127.0.0.1"); 
/*
  htons() eli host to network short muuttaa short integer tyypin
  luvun bittijärjestyksen "network byte orderiin".
*/
  osoite.sin_port        = htons(serverin_portti);

/*
  Yhdistä socketti. Tässä vaiheessa IP-pinkka aloittaa neuvottelut
  vastapelurin kanssa, ja mikäli connect kutsu palauttaa jotain muuta
  kuin 0:n, se tarkoittaa, että yhteydenotto syystä tai toisesta 
  epäonnistui.
*/
    if( 
        connect
        (
           sock,
           (struct sockaddr *)&osoite,
           sizeof(osoite)
        ) 
        != 0 
    )
    {
        //virheenkäsittely, sokettia ei voitu yhdistää.
    }
/*
  Kun yhteys on pystyssä, voidaan varsinainen viestien lähettäminen
  ja vastaanotto aloittaa: Tehdään siis viesti joka halutaan lähettää.
  Tässävaiheessa on syytä muistuttaa, että STREAM socketit kuten 
  TCP:n tapauksessa, eivät takaa sitä, että koko kerralla lähetetty
  sanoma tulee perille yhdellä kertaa ( yhdellä read() tai recv() 
  kutsulla). Siksi kun teet oman ohjelmasi, jossa haluat lähettää ja
  vastaanottaa dataa sockettien kautta, esim. vaihtaessasi tietoa
  prosessien välillä, on hyvä idea toteuttaa jokin oma protokolla.
  Yksinkertaisimmillaan vain päättämällä, että heti jokaisen viestin
  alussa on 32 bittiä (yksi integeri) joihin on talletettu lähetetyn
  datan pituus. UDP-socketteja käytettäessä, pakettien saapumis- 
  järjestys taas saattaa olla eri kuin lähetysjärjestys.
*/
    lahetettava_data=malloc(sizeof(int)+7*sizeof(char));
    if(NULL==lahetettava_data)
    {
        /*
            Virhekäsittely, muistin allokointi datan lähettämiseksi 
            epäonnistui.
        */
    }
 /*
   jätän koon ilmoittavan integerin viemän tilan huomioimatta sekä 
   lähetys että vastaanottopäässä 
 */
    datan_koko=7*sizeof(char);
    //Kopioi lähetetyn datan koko, lähetettävän datan alkuun.
    memcpy(lahetettava_data,(void *)&datan_koko, sizeof(int));
    //kopioi varsinainen viesti heti koon perään.
    memcpy
    (
        (void*)((char *)lahetettava_data)+sizeof(int),
        lahteva_sanoma,7*sizeof(char)
    );
    //Tähän olisi kannattanut käyttää structia :)

    //lähetä varsinainen viesti
    write(sock, lahetettava_data, datan_koko+sizeof(int));
    /*
    varaa tilaa luettavalle datalle.
    Luetaan ensin ensimmäiset 32 bittiä, ja tulkitaan se integerinä
    joka kertoo viestin koon. Tämän jälkeen luetaan loppu viesti.
    */

    datan_koko=recv(sock, (void *)&luettu_koko, sizeof(int), 0)
    if(datan_koko<sizeof(int))
    {
    /*
      virhekäsittely, luku palautti vähemmän kuin 4 tavua 
     (sizeof(int)). katso palauttiko recv 0, tai negatiivisen luvun,
     ja mikäli palautti tapahtui virhe tai yhteys suljettiin. Mikäli
     luku on positiivinen, mutta pienempi kuin sizeof(int) (ei pitäisi
     olla mahdollista!), lue uudelleen, ja aseta luettavaksi määräksi
     sizeof(int)-datan_koko jotta saat koko koon luettua. 
    */
    }

    // Luetaan nyt varsinainen data:
    luettu_data=malloc(luettu_koko);
    if(NULL==luettu_data)
    {
        //virhekäsittely.
    }
    datan_koko=0;
    while(datan_koko<luettu_koko)
    {
        if( 
            ( luvun_paluuarvo=recv
                (
                    sock,
                    (void *)(((char *) luettu_data) + datan_koko),
                    luettu_koko-datan_koko, 0
                )
            ) 
            <= 0
        )
        {
            /*
              virhekäsittely, recv palautti 0 tai negatiivisen luvun.
              0==yhteys suljettu, -1==virhe. Virhetapauksessa tutki
              errno saadaksesi tarkemman virhenumeron.
            */

        }
        datan_koko+=luvun_paluuarvo;
    }
    //luetun datan tulisi nyt olla luettu_data muuttujassa.
    /*
      Huomaa, tällainen printti on vaarallinen. Mikäli lähetetty data
      ei pääty NULL characteriin, tapahtuu luettaessa ylivuoto!
    */
    
    printf("Client - vastaanotettu: %s",(char *)luettu_data);
    //Lopuksi on hyvä käytäntä kutsua 
    close(sock);
    /*
      vaikkakin käyttöjärjestelmä toki sulkee roikkumaan jääneet 
      yhteydet, viimeistään prosessin päättyessä.
    */
    return EXIT_SUCCESS;
}

Esimerkki 2: Tulevia yhteyksiä kuuntelevan TCP/IP socketin teko (Server program)

#include <sys/socket.h> //otsikkotiedosto jossa esitellään socket ohjelmoinnissa tarpeellisia tietotyyppejä ja funktioita.
#include <unistd.h> //yleishyödyllinen kirjasto
#include <stdio.h> //perus I/O toiminnot
#include <stdlib.h> //malloc
#include <arpa/inet.h> //verkkoliikenne matskua
#include <string.h> //memcpy



/*
  Client koodissa olevasta viestin luonnin hankaluudesta 
  viisastuneena, luomme serveri koodiin viesti structin:
*/
#define MAX_DATA 1024

typedef struct viesti
{
    int viestin_koko;
    void data[MAX_DATA];
}viesti;

int main()
{
    /*
      socketti johon ulkopuolelta tulevat yhteydet saapuu kahva; 
      vertaa tiedoston avaaminen => kahva
    */
    int kuunteleva_socketti;
    /*
      Socketti joka luodaan varsinaista kommunikointia varten kun
      serveri hyväksyy kuuntelevaan sockettiin tulevan yhteyden. Näin
      kuunteleva socketti vapautuu kuuntelemaan uusia yhteyspyyntöjä.
    */
    int yhdistetty_socketti;

    struct sockaddr_in oma_osoite = {0};
    struct sockaddr_in clientin_osoite ={0};
    socklen_t osoitteen_pituus;
    unsigned short int kuunneltava_portti=12345;
    int luettu_koko;
    int datan_koko;
    viesti vastaanotettu_sanoma;
    viesti vastaus_sanoma;
    int luvun_paluuarvo;
 
//Luodaan socketti jota kuunnellaan, samoin kuin clientin tapauksessa.
    if( (kuunteleva_socketti=socket(AF_INET, SOCK_STREAM, 0)) < 0)
    {
 //virhekäsittely, socketin luonti epäonnistui
    }
// Sitten asetetaan oman serverin tiedot sockaddr_in structiin
    oma_osoite.sin_family = AF_INET;
    oma_osoite.sin_addr.s_addr = htonl(INADDR_ANY);
    oma_osoite.sin_port = htons(kuunneltava_portti);
    /*
      Tässävaiheessa client koodissa luotiin yhteys kuuntelevaan
      koneeseen. Nyt kun perustiedot on saatu kasaan, serverikoneessa
      sidotaan luotu socketti porttiin jota tahdotaan kuunnella, ja 
      aletaan "kuuntelemaan" yhteydenottoja.
      Huomaa, että 'listen' kutsu ei ole blokkaava! Eli ohjelman 
      suoritus jatkuu välittömästi eteenpäin, riippumatta siitä 
      tuleeko clientiltä yhteydenottoa vai ei!
    */
    if 
    (
        bind
       (
           kuunteleva_socketti,
           (struct sockaddr *) &oma_osoite,
           sizeof(oma_osoite)
       ) 
       < 0
    )
    {
        //virhekäsittely, socketin sitominen porttiin epäonnistui.
    }
    /*
      listen funktion toinen parametri, kertoo montako clientin 
      yhteyttä serveri pitää 'jonossa' odottamassa hyväksyntää.
    */
    if(-1==listen(kuunteleva_socketti, 1))
    {
        //Virhekäsittely, listen epäonnistui.
    }
    /*
      Nyt tapahtuu varsinainen yhteyksien vastaanotto. Huomaa, accept
      on blokkaava kutsu, ohjelman suoritus pysähtyy kunnes ensimmäinen
      yhteydenottopyyntö saapuu
    */
    osoitteen_pituus = sizeof(clientin_osoite);
    
    yhdistetty_socketti = accept
    (
        kuunteleva_socketti,
        (struct sockaddr *) &clientin_osoite,
        &osoitteen_pituus
    );
    if (yhdistetty_socketti < 0) 
    {
        //virhekäsittely, yhteyden hyväksyntä epäonnistui!
    }
    /*
      Huomaa, accept päivittää client_ddress structiin clientin tiedot,
      joten voit jossain määrin valvoa mistä tulevien yhteydenottojen
      kanssa tahdot jatkaa, ja mitkä tahdot lopettaa saman tien.
    */
        //vastaanota ensimmäiset 32 bittiä (viestin koko)
    luettu_koko=recv(
        yhdistetty_socketti,
        (void *)&vastaanotettu_sanoma.viestin_koko,
        sizeof(int),
        0
    );
    if(luettu_koko<(int)sizeof(int))
    {
        //virhekäsittely
    }
    if(vastaanotettu_sanoma.viestin_koko>MAX_DATA-sizeof(int))
    {
        printf("Liian iso sanoma => lopetan");
        return EXIT_FAILURE;
    }
    //vastaanota loppu viesti:
    

    datan_koko=0;
    while(datan_koko<vastaanotettu_sanoma.viestin_koko)
    {
        if( 
            (luvun_paluuarvo=recv
            (
                yhdistetty_socketti,
                ((char *)vastaanotettu_sanoma.data)+datan_koko,
                vastaanotettu_sanoma.viestin_koko-datan_koko,
                0
            )
            ) 
            <= 0
        )
        {
        /*
          virhekäsittely, recv palautti 0 tai negatiivisen luvun. 
          0==yhteys suljettu, -1==virhe. Virhetapauksessa tutki errno
          saadaksesi tarkemman virhenumeron.
        */

        }
        datan_koko+=luvun_paluuarvo;
        luvun_paluuarvo=0;
    }
    //luetun datan tulisi nyt olla luvun_paluuarvo muuttujassa.
    printf("Saatu: %s",(char *)vastaanotettu_sanoma.data);
    // Läheta vastaus

    
    memset(vastaus_sanoma.data,0,MAX_DATA);
    vastaus_sanoma.viestin_koko=4*sizeof(char);
    strncpy((char *)vastaus_sanoma.data,"bar",4*sizeof(char));
    write
    (
        yhdistetty_socketti,
        (void *)&vastaus_sanoma,
        sizeof(int)+4*sizeof(char)
    );
    //Lopuksi on hyvä käytäntä kutsua 
    close(yhdistetty_socketti);
    close(kuunteleva_socketti);
    return EXIT_SUCCESS;
}

Pari sanaa vielä...
Ehkä yleisin tapa toteuttaa serveriohjelmat on, että listen funktion jälkeen tehdään ikilooppi, jossa kutsutaan acceptia. Ja aina kun uusi yhteys tulee, 'forkataan' uusi prosessi (tai tehdään uusi threadi) jossa yhteyttä käytetään, alkuperäisen prosessin aloittaessa loopissa uuden kierroksen valmiina vastaanottamaan seuraavan sisääntulevan yhteyden.

Esimerkki 3: Select()

Ja vielä lupaamani select() esimerkki:
Allaolevalle funktiolle annetaan tutkittava socketti, ja se hyödyntää select() funktiota tarkistaakseen onko uutta dataa saatavilla vai ei. select():iä voi myös käyttää tutkimaan voiko sockettiin kirjoittaa, tai onko socketissa jokin poikkeus käsiteltäväksi. Tähän select funktio käyttää fd_set tyyppisiä olioita, siten että luettavuuden, kirjoitettavuuden ja poikkeuksen tarkistamiseksi on määritettävä oma fd_setti. Seuraavassa esimerkissä jätän kirjoitus ja poikkeus setit läpikäymättä, sillä kirjoitussetti on samanlainen kuin lukusettikin, ja poikkeukset taas menevät pitkälle tämän blogiartikkelin ulkopuolelle.


int onko_uutta_dataa_luettavissa(int sock)
{
    //Tee fd_set lukemiselle
    fd_set fdset_luku;

    int paluuarvo=-1;
    /*
      select() kutsun voi asettaa blockkaamaan haluamakseen aikaa,
      määrittämällä blokkaus ajan timeval tyyppiseen structiin
    */
    struct timeval time;
    //alustetaan tutkittava fd_setti 'ei mitään uutta' tilaan
    FD_ZERO(&fdset_luku);
    //sidotaan tutkittava socketti fdsettiin
    FD_SET(sock,&fdset_luku);
    /*
      koska en halua selectin blokkaavan ohjelman ajoa,
      nollaan timeval structin
    */
    memset(&time,0,sizeof(time));
    //kutsutaan selectiä asettaen muut kuin luku fdsetin nollaksi.
    paluuarvo=select(sock+1,&fdset_luku,0,0,&time);
    if(paluuarvo==-1)
    {
        //virhekäsittely, select epäonnistui!
    }
    //luetaan fdsetistä onko socketissa uutta dataa odottamassa.
    if(FD_ISSET(sock,&fdset_luku))
    {
        //Uutta dataa saatavilla!!!
 return 1;
    }
    //Ei uutta luettavaa :(
    return 0;
}

Loppuun vielä lyhyehkö yhteenveto winsock (windows sockettien) ja UNIX sockettien eroista:

Windowsissa sockettien esittely tapahtuu kirjastossa winsock.h, ei sys/socket.h
Windowsissa socketin kahva ei ole pelkkä integer, vaan tyyppiä SOCKET
Windowsissa ennen socket kirjaston käyttöönottoa tulee ajaa sokettikirjastolle startti. Se tapahtuu tekemällä seuraavat temput:

1. luo muuttuja
WSADATA wsadata;
2. aja funktio WSAStartup ja varmista että sen paluuarvo ei ole SOCKET_ERROR
WSAStartup(MAKEWORD(2, 2), &wsadata);

Windowsissa socketti suljetaan functiolla closesocket() ei close()
Lopuksi windowsissa ajetaan funktio:
WSACleanup()

Muuta huomioitavaa:
Windowsissa select():iä voi käyttää vain sockettien tutkimiseen.

Ja vielä viimeiset sanat, windows puolella sockettien käyttöä pääsee helposti kokeilemaan asentamalla ilmaisen DEV-CPP IDE:n (integrated developement environment == kääntäjä, linkkeri ja koodi editori samassa paketissa), ja asentamalla help valikon päivitysten kautta socket lisäosan. Linux maailmassa socketit kuuluvatkin vakiokalustoon.