[VB.NET 2005] Threading/threadpool probleem

[Verwijderd]

ik wil 2 handelingen uitvoeren, maar de 2e mag pas starten als de 1e klaar is,
ik heb als voorbeeld een filecopy genomen, ik kopieer een bestand van 350 MB via het netwerk
naar een andere pc, vervolgens doe ik hetzelfde proces nogmaals.
het probleem is dat ie niet echt wacht tot de 1e klaar is maar gelijk doorgaat naar de 2e.
dat is ook logisch omdat dat er niet ingebouwd zit. ik ben dus op zoek naar een soort lock ofzo wat wacht tot file.copy daadwerkelijk de file helemaal heeft gekopieerd en dan pas doorgaat.
ik heb het geprobeerd met SyncLock maar daarmee gaat ie niet door naar de 2e handeling.
Uiteindelijk is het de bedoeling dat er honderden images worden bewerkt, gerenamed en gekopieerd, op de normale manier loopt dan heel het geheugen vol, vandaar dat ik naar een oplossing zoek waarbij de volgende bewerking pas start als de vorige klaar is.
ik heb daarbij op internet gezocht en ik kwam toen op een threadpool, daarbij heb ik de volgende code geprobeerd:

Visual Basic .NET:

    Private Sub AC_FileCopy(ByVal state As Object)
        IO.File.Copy("D:\file.pdf", "\\testpc\test\testfile.pdf", True)
        CType(state, AutoResetEvent).Set()
    End Sub
    Private Sub AC_FileCopy(ByVal state As Object)
        IO.File.Copy("D:\file.pdf", "\\testpc\test\testfile2.pdf", True)
        CType(state, AutoResetEvent).Set()
    End Sub

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim AIsDone As New AutoResetEvent(False)
        Dim BIsDone As New AutoResetEvent(False)
        ThreadPool.QueueUserWorkItem(New WaitCallback(AddressOf AC_FileCopy), AIsDone)
        ThreadPool.QueueUserWorkItem(New WaitCallback(AddressOf AC_FileCopy2), BIsDone)

        Dim ThreadCount, ThreadPorts As Integer
        ThreadPool.GetAvailableThreads(ThreadCount, ThreadPorts)

        AIsDone.WaitOne()
        BIsDone.WaitOne()
    End Sub

het probleem heb ik dus al aangegeven dat ie niet wacht tot ie klaar is met in dit geval kopieeren maar gelijk doorgaat naar de volgende. ik hoop dat iemand mij kan helpen met waar ik op moet zoeken bijvoorbeeld of kan aangeven wat ik fout doe.

[Niemand_Anders]

Ik zou zeggen kijk eens naar het Queue object.

C#:

Queue<WaitCallBack> threadQueue = new Queue<WaitCallBack>();
threadQueue.Add(New WaitCallback(AddressOf AC_FileCopy));
threadQueue.Add(New WaitCallback(AddressOf AC_FileCopy2));

Vervolgens kun je het queue object doorgeven aan de functie welke de bestanden moet gaan kopieren. Wat ik niet begrijp is waarom je dit asynchroon scrijft (threads werken parallel), terwijl je de bestanden synchroon (sequentieel) wilt kopieren.

Het idee van threads is juist dat er meerdere taken tegelijktijd worden uitgevoerd.

Een andere oplossing dat je een FileCopy functie schrijft welke een source en target verwacht en File.Copy vanuit een lock aanroept:

C#:

public void FileCopy(string source, string target)
{
  lock(this)
  {
    File.Copy(source, target)
  }
}

Oplossingen zat zou ik zeggen. Persoonlijk heb ik een beetje het idee dat je het programma niet hebt uitgewerkt en daardoor niet doorhebt wat je aan het bouwen bent of waar je mee bezig bent.

[RobIII]

^^ Wat hij zegt. En waarom is state een object en niet (say) een enum?

[Verwijderd]

ik heb de oplossing gevonden, door middel van een monitor lock.

Visual Basic .NET:

Public Shared MonitorLock As Object = New Object()

    Private Sub AC_FileCopy(ByVal state As Object)
        Monitor.Enter(MonitorLock)
        IO.File.Copy("D:\file.pdf", "\\testpc\test\testfile.pdf", True) 
        Monitor.Exit(MonitorLock)
        CType(state, AutoResetEvent).Set()
    End Sub

ik had het al eens met een lock geprobeerd want ik dacht al dat het daar in zou zitten,
dat werkte niet en deze oplossing werkt dus wel.

op de vraag van RobIII terug te komen: dat weet ik zelf ook niet, ik heb dat uit een voorbeeld en er stond alleen bij dat het op die manier moest en niet waarom.
bedankt voor jullie hulp

[RobIII]

Verwijderd schreef op maandag 05 november 2007 @ 12:18:
op de vraag van RobIII terug te komen: dat weet ik zelf ook niet, ik heb dat uit een voorbeeld en er stond alleen bij dat het op die manier moest en niet waarom.

Ik denk dat er niet stond dat het op die manier moest, maar dat het voorbeeld nou eenmaal zo was. Dat is iets anders. Bij programmeren dien je zelf ook nog na te denken, en als je iets anders nodig hebt is het echt geen doodzonde om dat gewoon aan te passen naar je wens hoor

[Verwijderd]

RobIII schreef op maandag 05 november 2007 @ 12:20:
[...]

Ik denk dat er niet stond dat het op die manier moest, maar dat het voorbeeld nou eenmaal zo was. Dat is iets anders. Bij programmeren dien je zelf ook nog na te denken, en als je iets anders nodig hebt is het echt geen doodzonde om dat gewoon aan te passen naar je wens hoor

nee weet ik, beter goed gestolen dan slecht verzonnen zeggen ze toch .
maar ik lees bijna altijd wel de commentaar en/of uitleg die erbij staat, maar meestal is die beknopt.

[YakuzA]

Ik blijf het een beetje raar vinden, standaard als je gewoon de functies zonder threadpool runt gebeuren ze sequentieel.

Dan introduceer je de threadpool omdat je ze blijkbaar parrallel wil uitvoeren.
Vervolgens ga je het probleem dat je zelf introduceert weer oplossen met een lock om het sequentieel te maken.

Was dit in het kader van de werkverschaffing?

Je eerste voorbeeldje klopt trouwens ook niet, de 2 functienamen zijn hetzelfde

[Verwijderd]

ja sorry daar moet een 2 achter bij de 2e functie.
ik hoopte met threadpool om ze niet parallel uit te voeren, het voorbeeld op internet werkte ook niet parallel maar opeenvolgend en dat wou ik ook. ik denk bij een threadpool aan een wachtrij van threads, daarvoor heb je toch ook QueueUserWorkItem. en bij elke thread zeg je WaitOne, dat lijkt mij dat de volgende thread wacht tot de huidige klaar is. maar zonder die monitor lock voert ie wel een voor een de file.copies uit alleen houdt hij er geen rekening mee dat het een groot bestand is wat tijd nodig heeft om klaar te zijn met het kopieeren. dat is nu opgelost.