CreateThread always ok, but CloseHandle fails sometimes

Started by cobold, May 22, 2009, 01:39:45 PM

Previous topic - Next topic

drizz

I'm not really sure what you are trying to do there :P, you should definitely use some sort of timer object.
But if you must do it that way then use Critical Section in the thread.

main:
  increment var

thread:
  sleep 
  entercs
  print var
  leavecs


read more here:
http://msdn.microsoft.com/en-us/library/ms686360(VS.85).aspx
The truth cannot be learned ... it can only be recognized.

cobold

Quote from: drizz on May 25, 2009, 01:26:00 PM
I'm not really sure what you are trying to do there :P, you should definitely use some sort of timer object.
....
Well I'm only trying to get some knowledge about thread-programming. So the program has no special purpose.
My idea was to

  • create a simple time-comsuming task (adding up a qword in this case)
  • then create simple thread-proc that displays the value of the variable and the time
So the only purpose is to get a feeling for this kind of coding, the possible exceptions and how to handle them. You are right that one would use a timer object if the purpose is to display something in intervalls. But can you user timer objects in console mode? I don't think so, because with SetTimer you need a hWnd and have to process timer messages. As far as I know, consoleapps don't have a message-loop?

drizz

Yes, when it comes to console you don't even need a thread because it doesn't need "refreshing" you can block it just fine, unlike a gui where everything freezes :)

IMO, time consuming task should be in a thread and display in main :)

For a learning task i have an idea!

code or take sorting algos quicksort, bubblesort, insertsort
put them all in their own thread, sorting a copy of a randomized array (bigger -> more time consuming).

it would be a nice way of learning how to use synchronisation apis

cheers




The truth cannot be learned ... it can only be recognized.

MichaelW

#18
In the time I spent on it, I found no way to get a normal timer to work in a console app, but a Multimedia timer is no problem.

; ««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
    include \masm32\include\winmm.inc
    includelib \masm32\lib\winmm.lib
; ««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    .data
      timerId dd 0
      hEvent  dd 0
      count   dd 0
    .code
; ««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

TimeProc proc uID:DWORD, uMsg:DWORD, dwUser:DWORD, dw1:DWORD, dw2:DWORD

    .IF count == 0
      print "TimeProc thread ID "
      invoke GetCurrentThreadId
      print ustr$(eax),13,10,13,10
    .ENDIF
    inc count
    print ustr$(count),9
    ret

TimeProc endp

; ««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
start:
; ««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

    print "timerId "
    invoke timeSetEvent, 100, 1, TimeProc, 0, TIME_PERIODIC
    mov timerId, eax
    print ustr$(timerId),13,10

    print "Program thread ID "
    invoke GetCurrentThreadId
    print ustr$(eax),13,10

    .WHILE count < 50
    .ENDW

    print chr$(13,10)
    print "timeKillEvent rval "
    invoke timeKillEvent, timerId
    print ustr$(eax),13,10,13,10

    invoke CreateEvent, 0, TRUE, FALSE, NULL
    mov hEvent, eax

    ;-------------------------------------------------------------------
    ; If TIME_PERIODIC is not specified, then the timer event type will
    ; be TIME_ONESHOT, which apparently cancels the timer after one
    ; event, so a subsequent timeKillEvent will return TIMERR_NOCANDO.
    ;-------------------------------------------------------------------

    print "timerId "
    invoke timeSetEvent, 3000, 1, hEvent, 0,
                                  TIME_PERIODIC or TIME_CALLBACK_EVENT_SET
    mov timerId, eax
    print ustr$(timerId),13,10,13,10

    ;----------------------------------------------------
    ; Suspend program thread until MM timer event fires.
    ;----------------------------------------------------

    print "waiting for timer event to fire...",13,10,13,10

    invoke WaitForSingleObject, hEvent, INFINITE

    print "timeKillEvent rval "
    invoke timeKillEvent, timerId
    print ustr$(eax),13,10,13,10

    inkey "Press any key to exit..."
    exit

; ««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
end start

eschew obfuscation

dedndave

QuoteI can find no way to get a normal timer to work in a console app, but a Multimedia timer is no problem

huh ?  :eek

that is Michael talking, right ?
that does not sound like a Michael sentance to me - lol

i see you got my pm about threading - did i peak your curiosity ?

NightWare

Quote from: drizz on May 23, 2009, 02:54:53 PM
2.
Be careful when using the same global var from two threads (main thread+work thread). For anything more complicated you have to use some locking mechanism, you can't access/modify it just like that.
hmm, it's not exactly that, it's totally possible to use the same global variable, but you must code your thread with (in mind) the possibility that your main thread can change the value/s (by coding entire section depending of the value). otherwise you're right on the principle... when using a thread you must understand that the main thread can modify global value/s at any moment.  :wink

UtillMasm

c:\china>\masm32\bin\ml.exe /c /coff /nologo test.asm
Assembling: test.asm
test.asm(49) : error A2006: undefined symbol : TIME_CALLBACK_EVENT_SET
test.asm(49) : error A2114: INVOKE argument type mismatch : argument : 5
Press any key to continue . . .

:red

dedndave

this brings up a question that i have....

i understand most of what i have read about synchronization and locking objects
i am trying to do a little syncronization between threads without using function calls, as i want a quicker response
now, this will probably draw some critisism, but that's ok - i'm used to it - lol
in days of old, this kind of thing worked rather well - i am not so sure how the pentum cache scheme will deal

thread1 proc

        xor     eax,eax

th1_00: cmp     eax,0FFFFFFFFh
locked  label   dword
        jnz     th1_00

;sync'ed code

thread1 endp


then, in another thread, i set locked-4 to 0....


        xor     eax,eax
        mov     locked-4,eax

the question i have is this...
will the cached (queue) code kill me ?

UtillMasm

---------- Find in Files ----------
"C:\Cygwin\usr\include\w32api\mmsystem.h"(387,9):#define TIME_CALLBACK_EVENT_SET 16
"C:\GoASM\headers\mmsystem.h"(1139,9):#define TIME_CALLBACK_EVENT_SET  0x0010
"C:\Program Files\Microsoft SDKs\Windows\v6.0\Include\MMSystem.h"(2199,9):#define TIME_CALLBACK_EVENT_SET     0x0010  /* callback is event - use SetEvent */
"C:\WinDDK\6001.18001\inc\api\mmsystem.h"(2198,9):#define TIME_CALLBACK_EVENT_SET     0x0010  /* callback is event - use SetEvent */
4 occurrences have been found in 4 files.
Output completed (2 sec consumed)

so, add this line to '\masm32\include\windows.inc' file:
TIME_CALLBACK_EVENT_SET equ 10h
c:\china>\masm32\bin\ml.exe /c /coff /Fotest.obj /nologo test.asm
c:\china>\masm32\bin\link.exe /subsystem:console /out:test.exe /nologo test.obj
c:\china>test.exe
timerId 16
Primary thread ID 12728
TimeProc thread ID 7444

1       2       3       4       5       6       7       8       9       10
11      12      13      14      15      16      17      18      19      20
21      22      23      24      25      26      27      28      29      30
31      32      33      34      35      36      37      38      39      40
41      42      43      44      45      46      47      48      49
50      timeKillEvent rval 0

timerId 32

waiting for timer event to fire...

timeKillEvent rval 0

Press any key to exit...

c:\china>

MichaelW

UtillMasm,

I'm using MASM32 version 9r with SP2, and windows.inc version 1.4c BETA 20 July 2007 that I apparently got here:

http://www.masm32.com/board/index.php?topic=7677.0

And in that version of windows.inc TIME_CALLBACK_EVENT_SET is defined, and it probably is defined in all later versions.

Looking back at the version 1.30 Release 7 March 2006 that was included with MASM32 version 9r, TIME_CALLBACK_EVENT_SET is not defined, and AFAIK SP2 did not update windows.inc.

eschew obfuscation

UtillMasm


dedndave

i have masm32 v10r (i think that's right) - windows.inc 6-4-2008
TIME_CALLBACK_EVENT_SET equ 10h

disappointed   :(  no response on my self-modifying code
(hint Michael)

UtillMasm


MichaelW

Quoteno response on my self-modifying code

Within the limits of the code that you posted I can't see any reason why it would not work, but I also can't see any reason to use self-modifying code.
eschew obfuscation

NightWare

Quote from: dedndave on May 26, 2009, 02:06:22 AM
the question i have is this...
will the cached (queue) code kill me ?
the cache contain always the more recently used algos, since the os alternate the threads i don't see any possible problem/conflict (but i must admit i've never used this technic)