HowTo. Indexacion MutiThread

[thefull]

Amigos, aquí tenéis una implementación de una indexacion multihilo, en este caso, me centro en NTX, que es lo que tengo que usar.
Funciona solamente con Harbour, no con xHarbour.

Para compilarlo , hbmk2 test -mt
ejecutar test 1 // Crea las dbfs de prueba

NOTA:Atentos, es un concepto de implementación, NO os pongais a crear hilos a cascoporro

Espero que veáis lo curioso que resulta ver el experimento

Code: Select all  Expand view

/*
   Example multiThreads index.
   One thread by table , and one thread by index.
   2010 Rafa Carmona

   Thread Main
        |--------->  Thhread child table for test.dbf
        |                        |----> Thread child index fname
        |                        |
        |                        |----->Thread child index fcode
        |
        |--------->  Thhread child table for test2.dbf
                                |----->Thread child index fname2


 */
#include "hbthread.ch"

proc Main( uCreate )
    Local nSeconds
    Local aFiles  := { "test", "test2" }        // Arrays files dbf
    Local aNtx    := { { "fname", "fcode" },;   // files index for test
                       { "fName2" } }           // files index for test2
    Local aExpr   := { { "name", "code" },;
                       { "dtos(fecha)+str(code)" }  }     // Expresions
    Local cDbf

    if empty( lCreate )
       lCreate := "0"
    endif

    setmode( 25,80 )
    cls

    if uCreate = "1"
       ? "Create test.dbf and test2.dbf"
       dbCreate("test",{ {"name","C",1,0 },{"code","N",7,0 } } )
       use test
       while lastRec() < 1000000
             dbAppend()
             field->name := chr( recno() )
             field->code := recno()
       enddo
       close
       dbCreate("test2",{ {"fecha","D",8,0 },{"code","N",7,0 } } )
       use test2
       while lastRec() < 1000000
             dbAppend()
             field->fecha := date() + recno()
             field->code := recno()
       enddo
       close
    endif

    cls
    // Threads
    nSeconds := Seconds()
    for each cDbf in aFiles
       ? "Procesando..: " + cDbf
       hb_threadStart( @aCreateIndexe(), cDbf, aNtx[ cDbf:__enumindex ], aExpr[ cDbf:__enumindex ], cDbf:__enumindex  )
    next

    ? "Esperando a los hilos ...."
    hb_threadWaitForAll()

    ? hb_valTostr( Seconds() - nSeconds )

    ? "Salgo"

return

function aCreateIndexe( cFile, aNtx, aExpr, nPosDbf )
       Local nContador := 1
       Local cFileNtx, cExpr
       Local nLong := Len( aNtx )
       Local aThreads := {}
       Local cAlias

       use ( cFile )
       cAlias := alias()
       hb_dbDetach( cAlias )  // Libero el alias

       for each cFileNtx in aNtx
           cExpr  := aExpr[ cFileNtx:__enumindex ]
           nContador := 1
           nPos := cFileNtx:__enumindex
           aadd( aThreads, hb_threadStart( @crea(), cAlias,cExpr, cFileNtx, nPos, nPosDbf ) )
       next

       aEval( aThreads, { |x| hb_threadJoin( x ) } )  // Espera que termine los hilos hijos
       hb_dbRequest( cAlias, , , .T.)  // Restaura el alias
       close

RETURN NIL

proc crea( cAlias, cExpr, cFileNtx, nPos, nPosDbf )
      Local nContador := 1

       hb_dbRequest( cAlias, , , .T.)  // Restaura el alias

       INDEX ON &(cExpr) TO &(cFileNtx) ;
             EVAL {|| hb_dispOutAt( nPosDbf, iif( nPos = 1, 20, 40 ), alltrim( hb_valtostr( nContador) ), "GR+/N" ), nContador += INT( LASTREC() / 100 ) , .T. } ;
             EVERY INT( LASTREC() / 100 )

       hb_dbDetach( cAlias )          // Libera el alias


return
 

[Carles]

Hola Rafa, cuanto tiempo !

Yo creo q en estos tipo de procesos NO tiene mucho sentido usar threads, es mas, no se hasta que punto puede ser incluso mas lento !. Quizas en los tipicos procesos de server si, porque puedes estar ejecutando un thread con muchas carga y paralelamente ir vaciando otras peticiones....

Encantant de veuret per aqui...

[Marcelo Via Giglio]

Carles,

como que no?, si tienes varios TAG (como creo que es el ejemplo en el caso de NTX indices) cada uno va por un thread, y claro que sera mas eficiente, ahora no se que estructura de datos son los inideces? B-tree o algo asi, alli mismo se podria utilizar thread al estilo de un QuickSOrt, claro de esto ultimo depende de la estructura.

No estoy seguro pero creo que ya han optimizado la creacion de indices, que en lugar de hacer una pasada por indice o tag, solo hacen una y los crean al mismo tiempo, por lo menos creo que asi lo hace ADS.

Interesante el tema gracias por compartir, y claro Carles puede que me equivoque en ese caso mis disculpas

solo una opinion

Marcelo

[Carles]

Marcelo,

Quizas me equivoque yo . El ejemplo es interesante y muy bueno para ver el uso de los threads (gràcies Rafa), tan solo he comentado que en harbour y en la creacion de indices quizas no tiene sentido y ganes en velocidad de ejecucion. Yo hice unas pruebas hace tiempo y no consegui optimizar el codigo en velocidad . Quizas ahora tenga mas sentido y el uso de threads en la creacion de indices sea bueno. A veces la gente tiende a confundir q el uso de threads duplica, triplica, ... la velocidad de ejecucions de los procesos y creo q no es asi... (al menos en Harbour)

Es otra opinion y si me equivoco, lo siento tambien

[thefull]

Gusto verte por aquí Carles.

Por las pruebas que yo he realizado , hasta en la maquina virtual es más rápido el uso de 2 threads indexando , que uno a unoi.
Mi idea estaba enfocada hacia servidores, Xeon/AMD64 con 4 o más núcleos, y te aseguro que en estas máquinas es donde se nota el rendimiento y el uso de los threads.

Lógicamente, el crear 2000 hilos no te hace más rápido ni eficiente, pero , por las pruebas que he realizado, sobre 7 hilos y 2 nucleos , se nota, y mucho.
Ahora si tengo 2000 procesadores, pues creo 2000 hilos, y que el S.O se busque la vida

Además ahí tienes la base para hacer tus propias pruebas, aunque eso si, es MUY MEJORABLE, como limite de hilos por tabla y limite de hilos por indice, eso lo dejo como ejercicio