Newsgroup: it.comp.programmare
Titolo: Re: [lang. C / WIN32] CPU fritta dorata con "Pthreads"

 grazie di ogni aiuto
stai usando Windows come sistema operativo :-) ?
(Pessima scelta per Posix, una implementazione scarsa...)
Alcune note: in ambiente multitask/mulithread il thread
a piu' altra priorita' e' quello che (normalmente) viene eseguito
SEMPRE.
Tra thread alla stessa priorita' ( in dipendenza della politica
di scheduling, ma assumiamo pure quella piu' comune)
viene eseguito un round-robin: ovvero i thread si cedono
il controllo ciclicamente dopo n Tick di sistema.
Quindi se i thread NON sono alla stessa priorita',
solo quello alla piu' alta priorita' e READY puo' girare,
tutti gli altri sono bloccati fino a che' il thread  non
cede volontariamente il controllo.
Ne consegue che una implementazione multitask deve
prevedere meccanismi per cedere il controllo alla CPU
per permettere ad altri thread di girare, quando il
thread non ha nulla da fare.
Loop forever con polling  tipo
while(1)
{
     if(var) fai qualcosa
     else niente da fare
}
Sono da ABORRIRE ed evitare.
Invece, se il funzionamento e' a polling, e' necessario che
in qualche momento il thread ceda il controllo con una
funzione tipo sleep o equivalente.
while(1)
{
     if(var) fai qualcosa
     else Sleep(1ms);
}
Oppure (meglio) devi appendere i thread su un semaforo
o un mutex o una coda messaggi... Insomma, non devi
rimanere in loop foreved!
Bye
B.

 thread non ha nulla da fare.
Sotto Windows tipicamente accade con Sleep(0).
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

   
Anche qui, lo sleep(0), formalmente, forza un rescheduling prima che
un time slice sia scaduto tra i thread alla *stessa* priorita'.
Se il thread che fa sleep(0) e' quello con priorita' piu' alta, il
controllo torna allo stesso e l' effetto e' quello di bloccare tutto
lo stesso.
Per garantire almeno un tick agli altri thread *meno* prioritari,
va sempre eseguito uno sleep pari ad ameno due system ticks,
per avere almeno un system  tick utilizzabile.
(almeno nei sistemi Real time, cosa che win non e').
Ciao,
B.

un time slice sia scaduto tra i thread alla *stessa* priorita'.
Sì hai ragione. Tra thread di priorità differenti, ovviamente le cose
cambiano.

 (non quelli in modalità real-time).
In win 16 priorita' base e 16 di real-time (per quanto ne so..in Vista
non saprei). Boost/decay e' stato aggiunto per evitare che i processi in 
foreground della GUI decadesse troppo di performance, e per bilanciare 
le varie attivita, a discapito del determinismo.
In linux i meccanismi base sono quasi gli stessi di Win, ma le priorita' 
real-time (statiche) vanno da 1 a 99, mentre i processi ordinari hanno 
priorita' di base 0 e una priorita' dinamica assegnata con varie 
politiche: in effetti lo scheduler Linux e' piu' sofisticato e 
customizzabile di quello di Windows, anche se poi dipende dagli user
che scrivono applicazioni avvantaggiarsi o meno di queste feature ;-)
I SO real-time, poi hanno tutta una nutrita serie di politiche di 
scheduling per fine-tuning dell' applicazione...
Di fatto pero' , sia tra gli utenti di Win che di Lin, c'e' ben poca
cultura in questo campo... e ti trovi con quelle applicazioni che
fanno girare la clessidra e gli ammenicoli contemporaneamente ;-)
Ciao
B.

 non averlo mai.
Per eseguire un compito ogni tanto, devi usare la "sleep" per sospendere 
l'esecuzione. Tuttavia, non e' questo quello che fanno la maggior parte 
dei server. Solitamente un processo server attende un evento (o 
richiesta) e viene risvegliato solo quando avviene tale evento, cioe' il 
thread si pone in attesa su un oggetto di sincronizzazione, che puo' 
anche essere un socket o un file, e viene risvegliato quando in tale 
socket o file compaiono dei dati.
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

In win 16 priorita' base 
Win16... che bei ricordi la preistoria! :-)

 Avevo pensato a un polling ...
Male.
 > Però sono apertissimo a ogni idea.
Bene.
A meno che l'applicativo CAD/CAE, dopo aver inviato la richiesta al tuo 
modulo, voglia procedere con altre attività prima che il tuo modulo 
abbia completato l'elaborazione dei dati ricevuti, non vedo il motivo di 
una comunicazione asincrona.
Mi pare che si tratta di una normale chiamata di subroutine: il 
chiamante chiama la routine e ne attende il completamento.
Tale situazione si realizza appunto con una funzione da porre in una 
libreria a collegamento statico, o in una libreria a collegamento 
dinamico, o in un processo distinto comunicante tramite Remote Procedure 
Call (RPC) o protocolli analoghi (CORBA, SOAP, RMI in Java, Remoting in 
.NET).
Il metodo più semplice, classico e portabile pero' consiste nelle pipe 
senza nome, passando i dati in un formato testuale.


e tanto meno tra processi remoti.
Pthreads è una specifica generale che prevede i mutex come oggetti di
sincronizzazione e su piattaforme come Windows i mutex sono oggetti
kernel, quindi utilizzabili per sincronizzare processi, oltre -
ovviamente - ai thread. E in ogni caso una libreria per il threading è
un conto, una libreria per "comunicare tra processi" è un'altra cosa:
in quel caso si parla di IPC e le tecniche sono molteplici anche in
dipendenza dell'architettura. In caso di processi remoti e al variare
delle piattaforme, non ci sono molte strade: socket o pipes. In caso
di comunicazione locale ci sono i messaggi, i memory-mapped file e
tutto ciò che vale per le comunicazioni remote, naturalmente.

 delle piattaforme, non ci sono molte strade: socket o pipes.
A basso livello si', ma sopra i socket e le pipe con nome si appoggiano 
molti altri protocolli (per es.: RPC, DCOM, CORBA, SOAP, RMI, Remoting), 
e puo' essere opportuno usare uno di tali protocolli, senza usare 
esplicitamente ne' socket ne' pipe non nome.


esplicitamente ne' socket ne' pipe non nome.
Dipende. A me sembra che l'uso di uno di quei protocolli per risolvere
il problema dell'OP sia decisamente un overkill. Senza considerare che
DCOM č monopiattaforma e praticamente morto, CORBA č molto poco
utilizzato ormai, SOAP si usa praticamente solo per i Web Services
(non vorrai mica usare un ws per far comunicare due applicazioni,
vero?) e RMI č legato a Java e Java lo uso sufficientemente tutti i
giorni per dire che mi terrei lontano da qualunque cosa sia legata ad
esso, specie se si inseguono le performance. Non ho ancora studiato il
remoting di .NET ma le somiglianze che vedo finora col mondo Java osno
tali e tante da farmi sospettare che abbiamo seguito la via di Sun.
Credo sia molto piů semplice per l'OP tirare giů un protocollo
applicativo e implementarlo tramite socket, nudi e crudi.
 

 tuo suggerimento lo inizierò a sperimentare un po'.
Il compilatore Borland e' orientato a Windows, e nell'API di Windows le 
pipe senza nome si creano con la funzione CreatePipe.
Tieni presente che una pipe senza nome puo' essere usata solo 
localmente. Per usare una pipe via rete devi usare una pipe con nome.
Vedi:
http://msdn.microsoft.com/en-us/library/aa365781(VS.85).aspx
Dato che i linguaggi C e C++ non supportano meccanismi IPC, per avere la 
portabilita' con altri sistemi operativi, devi pero' usare le pipe 
Posix, creabili con la funzione "pipe".


 parola "pipe" manco nell'help 
E ha ragione, visto che si tratta di funzionalità strettamente dipendenti
dal sistema operativo e dalla piattaforma utilizzata. La colpa non è del
Borland C++, avresti lo stesso problema con qualsiasi altro compilatore.


 Borland C++, avresti lo stesso problema con qualsiasi altro compilatore.
La guida in linea dell'ambiente di sviluppo Microsoft documenta la 
funzione "_pipe", e cercando "pipe" si trovano le funzioni relative alle 
"pipe" utilizzabili dall'ambiente di sviluppo.
Normalmente i manuali forniti con i compilatori documentano tutte le 
funzioni utilizzabili da tali compilatori, non solamente quelle 
indipendenti dalla piattaforma.
Probabilmente, il compilatore Borland 6 non supporta tale funzione.


indipendenti dalla piattaforma.
No, i compilatori non documentano tutte le funzioni utilizzabili,
altrimenti ogni compilatore per Windows dovrebbe documentare l'API del
sistema operativo, il che è improponibile. Il compilatore non è tenuto
a documentare funzioni strettamente dipendenti dalla piattaforma. Le
pipe si possono usare con Borland C++ 6 pur non essendo documentato
l'uso nell'help del compilatore.

Addio, bcc32, mi mancherai :) - forse.
Ho l'impressione che tu faccia le tue scelte sulla base di una
pericolosa ignoranza. Il compilatore Borland in questione può lavorare
benissimo sotto Windows, il che vuol dire che può sfruttare benissimo
l'implementazione delle pipe offerta dal sistema operativo. Se solo tu
avessi voglia di approfondire la conoscenza dell'API di sistema...

 "passano" il compilatore, col borland no. 
Se il problema è che le librerie non sono supportate dal compilatore è un
conto (e in questo caso è ovvio che se hai librerie scritte per VS che
funzionano bene, ti conviene passare a VC++), ma in quanto a supporto per
il linguaggio non ci sono problemi, perché l'ultimo standard del C++
risale al 1998. Bada che io non ho mai detto che Borland C++ è molto
migliore di VS. Ancora una volta, confondi pericolosamente quello che ti
viene detto. Ti sto solo dicendo che prima di giudicare qualcosa devi
essere sicuro di conoscere bene la materia e purtroppo tu non dai l'idea
di conoscere bene nessun argomento specifico, visto il modo in cui parli
degli strumenti e della tua stessa competenza lascia troppo spazio per
pensare che gli errori siano dovuti al tuo modo di fare le cose, più che
ai tool utilizzati.


 l'uso nell'help del compilatore.
Giusto.
