Newsgroup: it.comp.appl.access
Titolo: Domanda per esperti ....

... A. Biso e' ovviamente escluso(*).
La domanda e' questa:
E' possibile fare del multithreading con Access?
 
(*) Unico intervento previsto l'immanente e immantinente trituramento 
dovuto all'oggetto.
-- 
 
ac (x=y-1)

"Alessandro Cara"  ha scritto nel messaggio 
news:l7eoq.87983$GZ3....@tornado.fastwebnet.it...

______________Risposta:
Ciao Ale,
non ho capito cosa vuoi ottenere.
Mi chiarisci?
MA 
 


Far eseguire piu' processi contemporaneamente?
Ovviamente ho scritto access e quindi si evitino sarchiaponi tipo API et 
similia. E' piu' che altro una domanda teorica (*). Hai fini di quello 
che mi serve non ci sono problemi. La domandina e' da "pierino" ed e' il 
riflesso riflusso "riflettutTo" su una negletta istruzione di access(**).
 
(*) Anche sul concetto di multithreading.
(**) Che ogni tanto risolve problemi "insormontabili"
-- 
 
ac (x=y-1)


wrote:

DoEvents c'entra qualche cosa?
 
Popi

 .... A. Biso e' ovviamente escluso(*).

pur avendo letto la specifica fatta a MA "piu' processi
contemporaneamente", ancora non riesco ad associare mentalmente la cosa ad
Access... che gli vuoi far fare?... fa un esempio.
 
-- 
--------------------------------
Pablitomf
 
Napoli sempre nel "Q"uore!
 

 - Mostra testo citato -
 
Capita a fagiUolo.....
 
Proprio ieri con un amico ho fatto un esperimento sul
multithreading ....
Scenario:
 
1 tabella, 2 campi, Id (contatore), Descr(testo [255])
Applicativo in C++ come FE
 
L'appicativo lancia la scrittura di x record (a scelta) in y threading
(a scelta)
 
Risultato:
1 thread : nessun problema
2,3,4,5 thread: 'a volte' nessun problema.....ma a volte si. L'errore
(da parte di jet credo) è la finestrella con "Impossibile completare
l'operazione per blocco record". Sembra che 'forse' Access nn
controlli il multithreading (con SQL server nn succede nulla di
strano. I tempi di esecuzione sono 1/10 di Access. Sembra proprio fare
fatica). L'errore non è controllabile ne ripetibile, nel senso che a
volte succede, a volte no. Rilanciando l'applicativo varie volte
magari ottengo la sequenza: concluso, errore, errore, errore,
concluso. Rilanciandolo altre 5 : errore, concluso, errore, concluso,
errore...sembra a caso.
Adesso, nn ho idea di come lavori Access/jet e win, cmq il risultato è
che Access nn gradisce il multithreading


Ovviamente si!
 
-- 
 
ac (x=y-1)


In questo io faccio sempre differenza fra "Access" ed "access". 
Normalmente quando parlo di "Access" mi riferisco piu' all'ambiente che 
alle caratteristiche di DBMS. In quel caso preferisco parlare di "Jet".
Rispetto a quello che scrivi, il problema mi sembra legato a "Jet" e tra 
l'altro e' un problema che, evidentemente, SQLServer (o altri DBMS) 
risolvono al loro interno (ma fino ad un certo punto, credo) e sempre 
credo e' risolvibile via software. Che un qualsiasi processo possa 
accedere ad una risorsa e che questa possa andare in conflitto perche' 
richiesta da altro processo ci sta tutto.
Per l'esempio che fai il risultato io me lo aspetterei a caso, come dici 
tu. I tempi di accesso ed esecuzione dei singoli "quanti" sono cosi 
piccoli che e' praticamente, credo, impossibile tenere "sincronizzati" i 
singoli "filamenti". Il sistema stesso (intendo il S.O.), di fatto, usa 
dei "semafori" (o delle "code"), per poter gestire il traffico. Questi 
semafori possono essere applicati a diversi livelli. Mi aspetto che un 
DBMS nato per per fare il *DBMS* (come si fa il maiuscolo del 
maiuscolo?) come minimo lo faccia. un "dbms" (piccolo, piccolo) come jet 
mi aspetto, invece, che per cose da grandi chieda all'estensore del 
codice di preoccuparsi della bisogna.
 
-- 
 
ac (x=y-1)


Che ne so..... magari mentre sta leggendo una miliardata di record fare 
magari altre cose, il caffe (i.e. mandare un segnale su qualche porta 
per accendere e far partire la macchinetta relativa e verificare a tempo 
quando comincia a uscire il caffe'), spedire una vagonata di e-mail, far 
fare il data entry su un form di acquisizione.... insomma cosette cosi'.
 
-- 
 
ac (x=y-1)

 - Mostra testo citato -
 
Nn entro troppo in merito perchè nn ne so abbastanza, ma a me risulta
che se io apro un thread, questo mi inizializza COM. Ogni thread
quindi chiama e rilascia COM. Se lancio tanti processi (quindi molti
processi con 1 thread per uno) il SO li isola. Evidentemente se lancio
un processo con + di 1 thread (quindi chiamo comunque + di 1 COM), non
hanno lo stesso isolamento (in relazione a Jet sia chiaro). Quindi nn
si parla propriamente di accessi concorrenti, ma di vero e proprio
multithread, cha 'access' (=jet) forse nn gradisce. Quando genero un
thread, è lui a instanziare COM correttamente, nn il programmatore,
quindi è il sistema che se ne occupa. Nei miei primi tentativi per la
concorrenza lanciavo 2 sessioni di Access sulla stessa tabella con
inserimenti sequenziale di 10000 records per testare gli inserimenti
concorrenti. Nessun problema. Qua invece con i thread jet si bomba
ogni 3x2, e SQL server no. Da qui, mi vien da pensare che nn sia una
buona idea il multithreading......e che nn centri manco il doevents,
che di fatto rilascia un attimo la risorsa per il SO (ma parliamo di
routine procedurali, mica di processi!!!!!)

 fare il data entry su un form di acquisizione.... insomma cosette cosi'.
 
ah ecco, ora mi e' chiaro...
se intendi questo, io lo faccio... invio dati in FTP, mentre faccio data
entry, leggo records , stampo (uso il gestionale insomma)... da due forms
diverse aperte contemporaneamente.


 "pierino"
 
;)
 
 
 
-- 
/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\

 similia. E' piu' che altro una domanda teorica (*). Hai fini di quello
 
 
Io lo so di essere escluso da certi circoli di iniziati accessisti
 
fortunatamente mi accettano in quelli dove non si assassina belluinamente 
l'italiano in questo modo...
 
 
Antonio
 
 


W il pane bianco!
 
-- 
 
ac (x=y-1)

 routine procedurali, mica di processi!!!!!)
 
Dai, i miei 2 cent erano solo un tirare ad indovinare per tirare fuori
al cryptico Alessandro una spiegazione in piu' sull'oggetto del
contendere! :)
 
Popi

 fare il data entry su un form di acquisizione.... insomma cosette cosi'.
 
Puoi tenere aperte più maschere contemporaneamente, anche nascoste, ognuna
fa il suo lavoro. Mentre una legge il suddetto Gigarecord l'altra ti
formatta l'hard-disk, ecc...
Al posto delle maschere puoi usare moduli di classe, soprattutto se devi
eseguire la stessa operazione in parallelo. Per esempio un modulo di
classe che analizza un'immagine: lo scrivi una volta sola e poi crei N
istanze, a ciascuna passi il nome di un file su cui lavorare.
Ciao.
-Marco-
 
 
-- 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it
 
 
 

On 24 Ott, 17:05, 
marco.pizzamig...@gmail.com
 (Marco Pizzamiglio)
wrote:

Ma così nn si parla di multithread......

> Ma così nn si parla di multithread......
 
no? e di che si parla?... il thread e' una suddivisione di un processo e il
multithreading e' il supporto che il processore ti da a gestire piu' thread...
se una maschera fa una cosa, un'altra ne fa un'altra, questo e' di fatto un
multithread.
Ti pare?



Penso di no......1 thread=1 processo ma mica 1 processo=1thread....
io lancio 3 istanze di access ho 3 processi = 3 thread
Qua si sta parlando di 1 processo contenente thread >2
Gli isolamenti che fa il SO mi paiono diversi...ma ripeto, non insisto
che nn son preparato a fondo sull'argomento
Vedo di documentarmi meglio

 Ciao.
Ciao Marco.
 
Non era questo il senso della cosa.
Quello che scrivi si puo' fare anche in una unica maschera.
La questione e' che mentre leggi il gigarecord se non rilasci il 
controllo (*) col cavolo che riesci a fare le altre cose.
I processi nei loro singoli "quanti" sono comunque serializzati e mentre 
access sta facendo una cosa non ne fa "contemporaneamente" un altra e 
questo e' valido anche per l'intero pezzo di ferro. Se ha una unica cpu 
non e' che serve "contemporaneamente" due processi (quando e' richiesto 
lavoro di CPU). Che poi la nostra "lenta" percezione ci faccia sembrare 
il contrario e' un altra questione (**)
 
(*) doevents o qualsiasi altra diavoleria, tipo le chiamate "callback" 
per poter interagire con attivita' che altrimenti non ti consentono di 
intervenire.
 
(**) tal quale la percezione che abbiamo di una qualsiasi trasmissione 
televisiva che e' fatta di "fotogrammi" che non vediamo a meno di 
rallentare la trasmissione.
-- 
 
ac (x=y-1)


wrote:

Ni.
Ci sono pensieri contrastanti sulla reale possibilità di fare
MultiThread anche con VB6... ma ti allego qualche discussione dalla
quale puoi forse capire la questione:
 
http://www.ioprogrammo.it/tipstricks/vb6multithread_senza_codice_terze_parti_ora_si_puograve-t17768.0.html
 
 
questo è concettualmente più elementare da capire:
 
http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=31786&lngWId=1
 
 
Ciao
@Alex

 Ma cosė nn si parla di multithread......
 
Ciao Fair87
Ho fatto inizialmente il post perche' mi annoiavo un po' e volevo 
"rivitalizzare" il "group".
Quello che dici e' corretto secondo i sacri testi che fanno 
"disquisizioni" altamente filosofiche sull'argomento.
Come al solito,credo, le cose sono relative.
Cos'e' per me un "thread"? E' una unita' logica elaborativa con un 
inizio uno svolgimento ed una fine.
Nell'esempio che ho fatto la lettura del gigarecord e' un "thread", la 
esecuzione di una routine di evento e' un "thread". Ora se si riesce a 
portare avanti due unita' elaborative "parallelamente" ai miei occhi 
(sottolineo *miei*) quello e' un multithread. Cio' detto se fossi il 
S.O. per me tutti i processi che riesco a portare avanti sono singoli 
thread. Questo non esclude che alcuni di miei thread a loro volta 
possano organizzarsi per innescare "unita' logiche elaborative" distinte 
al loro interno (comunque poi sempre da me devono venire). Anche nel tuo 
altro post in cui citavi i COM (mai voluto capire cosa diavolo fossero) 
per me non sono altro che affari che fanno qualche cosa e mantengono al 
loro interno lo stato fra chiamate differenti.
In quel post facevi riferimento, invece, a qualcosa che e' un dettaglio, 
importante, ma che non era nella mia intenzione introdurre e cioe' il 
concetto di "threadsafe" o meno.
E comunque quando viene rilasciato il controllo (ad es. doevents) se 
qualcuno si appropria del "bastone del comando" ed a sua volta non lo 
rilascia quello che tu chiamavi "attimo" puo' diventare una eternita'.
Ancora capita sotto Windows che qualche applicativo (se non Windows 
stesso) di incarta (non fa doevents, per banalizzare) e l'unica cosa che 
ci resta da fare e' staccare la spina (fisicamente).
 
 
 
-- 
 
ac (x=y-1)

 - Mostra testo citato -
 
eh.......questo dicevo io.....

 - Mostra testo citato -
 
Ciao Alessandro, tutto giusto quello che dici
io parlo da assoluto ignorante del campo, l'informatica era un hobby
che pian pianino ha preso una forma più prorompente ma sto ancora
cercando di recuperare tutte le info che stanno alla base....
Io dico quello che so: quando lancio un processo da access, lui (e nn
credo sia controllabile, o per lo meno nn ho idea di come si possa
fare) instanzia un COM (che è la maniera di Win di funzionare). Questo
'coso' farà il lavoro per il quale è stato chiamato. Se io volessi
fermarlo, non posso. Gli dico che ho bisogno che si fermi, lui, quando
risponde, si ferma quando nn fa danni. Se finisce, si autokilla. non
posso 'spegnerlo'. quando io lancio un processo (leggi thread) succede
una cosa così. Se lancio diversi processi (leggi diversi thread) sono
cmq cose sequenziali e separate (non posso, da codice, eseguire una
query SQL e, contemporaneamente, leggere un file. Devo fare prima uno
e poi l'altro o instanziare due 'access' o 2 form [classi]). Faccio un
esempio: ho sempre avuto problemi a rendere una lable 'dinamica',
ossia cambiare il contenuto per esempio in un loop. Usavo sempre
repaint, ma se per caso iconizzavo access, la form diventava bianca e
addio, fino alla fine del precesso nn mi tornava normale. Un doevents
al posto del repaint e tutto risolto. Ma chiedevo solo al sistema di
fare il suo lavoro di aggiornamento schermo mentre io gli 'succhiavo'
le risorse. quindi 1 processo e 1 thread. Diverso invece l'esempio che
ho fatto: da C++ lancio 2/3/4/5 thread nello stesso processo (non
lancio n 'access' o  n classi) che devono fare la stessa cosa
(inserire dati in una tabella con un campo contatore). Ecco, il
contatore e la gestione degli accessi concorrenti di Jet nn ce la
fanno ( ho uno zip con l'exe e l'mdb se interessa. Anche tutti i
sorgenti in C++ per ottenerlo). Ora, io so che il C++ nn ha nessun
problema a gestire i multithread (nn ho mai visto un linguaggio
arrivare tanto a 'basso livello' e win stesso è fatto in C++..) quindi
il problema è Jet. Tant'è che SQL server nn fa una piega.....da qui la
domanda sull'isolamento dei thread. Cmq la mia riposta alla tua
domanda iniziale, se fosse possibile o no usare il multithread con
access, è: jet nn ce la fa, e da codice nn saprei manco come fare a
chiamarlo.......that's all
 
Ciao
RobertoF

 e poi l'altro o instanziare due 'access' o 2 form [classi]). 
 
Quindi il fatto che io "USO" (e con "uso" intendo faccio tutto - scrivo,
cancello, consulto, eseguo sql, filtro, apro, chiudo, ecccccc... - ), e mentre
lo faccio il "sistema" invia file in FTP aggiornando percentuali, barre, label e
simili, e' perche' il mio Access e' posseduto come le tabelle di Tommaso? :D



Io nn riesco a lanciare in un'unica routine un loop che mi carica file
via ftp, esegue un'action query e magari mi fa pure vedere i dettagli
di una form contemporaneamente....
Se riesci a far funzionare una cosa del genere.......
:)

 :)
 
in un unica routine? no... in un unica non e' possibile ovviamente essendo ad
esecuzione "verticale"... ma lancio di routine contemporanee, si che lo e'... il
processo e' "Access", le routine "thread" da eseguire, le routine contemporanee
eseguite "multithread"... se tanto mi da tanto.... ;)



Ragazzi... state dicendo cose molto strane.
 
Parlate di MultiThread come fossero caramelle... ma non c'azzecca
NULLA il MultiThread con quello che state dicendo.
Nè Access nè VB6 possono, teoricamente, istanziare o lavorare in
Multithread, che non significa eseguire il codice in modalità
ASINCRONA.
E' ovvio che se lancio 10 Routine ASINCRONE ognuna teoricamente sembra
che vada per fatti suoi, ma non è così il Thread che le gestisce è
solo 1.
Il MultiThread invece è un'altra cosa, vale a dire che ogni chiamata è
resa indipendente dal processo che le chiama e dagli altri, il chè non
significa SINCRONA o ASINCRONA.
 
Chi la vorava in Assembler si ricorderà bene l'interrupt... per
banalizzare il concetto, Access esegue le chiamate che voi confondete
come MultiThread con la chiamata in Interrupt che è solo 1... ed ad
ogni passaggio ne esegue un pezzetto, se fa a tempo più di uno,
altrimenti memorizza negli STACK dove è arrivato ed alla successiva
prosegue... e questo sembrerebbe ASINCRONO indipendente.
Inchiadata la chiamata in Interrupt inchidato tutto quello che voi
definite MultiThread.
 
Il vero MultiThread è come poter generare delle chiamate Interrupt
indipendenti e definire per ognuna di esse cosa deve essere eseguito.
 
Chiaramente ho banalizzato molto il concetto, ma non saprei come
cercare di farvi capire meglio la cosa...
 
Per A.C. dovrebbe essere più chiaro, visto il suo passato di
esperienza un pò più vicino al mio, motivo per il quale ho puntato su
Assembler ed Interrupt.
 
Detto questo, tutto quello che avete detto è una cosa da non ridire
nell'ottica tecnica del MultiThread.....
 
;-)
 
Ribadisco che i 2 Link che vi ho sottoposto entrano un pò più nel
dettaglio, ma normalmente chi non passa a sviluppo con NET, e non
proviene da C o C++  non riesce ad afferrarne i concetti in modo
semplice.
 
@Alex

 ha scritto nel messaggio 
news:OIWoq.88696$GZ3....@tornado.fastwebnet.it...

ma anche quello cruscato non è male
 
Antonio 
 
 


 
Ovviamente quello che dici e' "molto" giusto dal punto di vista degli 
accademici della crusca (ogni riferimento e' voluto e non e' rivolto a 
te ;-{))
 
(*) A meno che non lo si voglia ed il gatto di Schroedinger sta sempre 
li a decidere se e' il caso di essere morto o vivo.
(**) questo a patto che il "controller" sia in grado di gestire il 
tutto, a prescindere da come lo fa
(***) e sempre nel rispetto delle capacita' intrinseche del sistema 
globale (trasformare l'acqua in ferro non e' teoricamente impossibile)
 
-- 
 
ac (x=y-1)

 ac (x=y-1)
 
Alessandro, mi sembra tu vada in deriva...
 
Cito tue parole del 1° Post:
"La domanda e' questa:
E' possibile fare del multithreading con Access?"
 
Ora se tu che sei un tecnico, hai scritto MultiThreading(cosa che per
gli informatici non è opinabile come l'osservatore esterno, altrimenti
ne avremmo parlato al Bar...) ma intendevi che volevi mangiare paste a
colazione con il cappuccio... credo abbiamo perso solo del tempo.
 
Ora puoi fare il filosofo o il para(chiappe) con crusca o meno... a
tua scelta.
 
Saluti
@Alex

 tua scelta.
 
Tra l'altro, in genere non scommetto, sarei pronto a scommettere che 
questa discussione a qualcosa o qualcuno puo' essere servita ed una 
"neoplasia" io continuo a chiamarla "tumore".
 
 
 
-- 
 
ac (x=y-1)


wrote:

Mittttico Benni (la Luisona)!!!!
Io cmq ho solo citato un'esperienza che ho avuto con un amico
programmatore in C++ (e quello LO GESTISCE SICURO il multithread, sia
il C++ che l'amico...)
Lo scenario è quello citato all'inizio, e son sicuro che è un
multithread e non un amenicolo strano. Bene, le mie conclusioni sono
che Jet (xchè di questo parlo) nn lo zuzza ma SQL server si. Poi tutto
il resto lo lascio a voi che questo lavoro lo fate di mestiere, il mio
contributo alla discussione può essere solo questa esperienza che
metto con piacere a disposizione, se a qualcuno servisse. Mi perdo
sicuramente a parlare di COM, Interrupt & affini perchè la mia
preparazione nn è tale, ma vi assicuro che l'eseguibile in c++
lavorava proprio sul multithrtead con Jet (ho a disposizione mdb, exe
ed anche sorgenti, e l'autorizzazione, visto che non è un mio lavoro,
a mandare tutto a chi voglia controllare o verificare) e Jet non gli
vuole molto bene.....Sono altrettanto sicuro che di multithread si
trattasse e non di qualche 'magia' di Jet o del SO. Poi il resto lo
lascio a voi che queste cose le fate di professione!!!!!!

 lascio a voi che queste cose le fate di professione!!!!!!
 
Chi sarebbero quelli che lo fanno per professione visto che lo hai
ribadito 2 volte...?
 
A.C. ormai è in pensione da anni, io faccio il mantenuto da una
vita... e poi non ho mai lavorato.
Pablito.... no lui è Napoletano, quindi non lavora, o se proprio lo fa
è in nero, e non vale.
Biso non parliamone... mangiare mangia, ma fai lavorare un romano... e
ti assumo come consulente.
 
L'unico che lavora quì sei tu, quindi se lo dici tu che lavori per me
è vangelo.
 
;-)
 
@Alex

 ha scritto nel messaggio 
news:5fdffd0e-a331-444d...@gk10g2000vbb.googlegroups.com...

Ciccio, romano ce sarai tu e tre quarti de la palazzina tua!!!
 
io sono di Civitavecchia, per la precisione...
 
 
Antonio 
 
 

 è in nero, e non vale.
 
..io? ...lavoro? ...brrrrrr... e che e'? :D


 ...io? ...lavoro? ...brrrrrr... e che e'? :D
 
PS. e se proprio vogliamo dirla tutta, "se" Pablito lavora, lavora in "marrone"
perche' sicuramente e' un lavoro di merda! :D



 
pablitoooooo
pablitooooooooo
 
che fai laggiůůůů
piccolo, lontano dalla vettaaaaaaa
 
ciaoooooooooooooooooooo
 
 
Antonio 
 
 

 ciaoooooooooooooooooooo
 
sto andando verso paesi stranieriiiiiiiiii... ho gia' segnato il tuo
indirizzoooooooo, ti mando una cartolinaaaaaaaaaaaaa... preferisci inghilterra,
germania o spagnaaaaaaaaaaaaaaa ??????... ad ogni modo poi tornero' in italia
non temere, e recuperero' quei 2 o 3 scalini che ci separanoooooooo tanto lo so,
tu mi aspetteraiiiiiiiiiiiiiiiii...
 
ciaoooooooooooooooooo ti saluto l'estero.


 tu mi aspetteraiiiiiiiiiiiiiiiii...
 
non fare brutta figuraaaaaa, ti tocca la fine del berluska con i 
sorrisettiiiiii di compatimento
 
Antonio 
 
 

 sorrisettiiiiii di compatimento
 
Intanto rimando a casa i primi della classe con la coda tra le gambe ;) 
credo ti convenga poco ridere, poi fa' tu ;)
