[Patch] Win32 thread primitives

2 views
Skip to first unread message

Vladimir Lipsky

unread,
May 2, 2005, 7:52:39 AM5/2/05
to perl6-i...@perl.org
This patch defines Win32 thread primitives. Actually it consists of the
following files:

threads.h.diff
thr_windows.h.diff
threads.t.diff
timer.t.diff

The patch had been applied, I mananged to pass all the tests from
t/pmc/thread.reast and t/pmc/timer.t but thread_4.pasm(don't know yet why it
fails)

The other files are needed the patch to compile and work properly:

events.c.diff - contains fix for correct deteremination of the tv_nsec
value. Now it is always equal to zero.
imcc.l.diff, imcc.y.diff et al - contain a dirty hack which prefixes the
CONST lexeme with underscore, otherwise CONST conflicts with MACRO from
windows header files. Probably the solution wwould be to prefix all the
lexemes with IMCC_ or whatever. Prefixing should be done for thread
primitives either.

events.c.diff
threads.t.diff
timer.t.diff
imcc.l.diff
imcc.y.diff
imclexer.c.diff
imcparser.c.diff
imcparser.h.diff
main.c.diff
thr_windows.h.diff
threads.h.diff

Leopold Toetsch

unread,
May 2, 2005, 8:44:52 AM5/2/05
to Vladimir Lipsky, perl6-i...@perl.org
Vladimir Lipsky wrote:
> This patch defines Win32 thread primitives.

Great.

> ...Actually it consists of the

> following files:
>
> threads.h.diff
> thr_windows.h.diff
> threads.t.diff
> timer.t.diff

Small nitpick - please provide just one patch file - applying is much
simpler then, or less work ;)

> The patch had been applied, I mananged to pass all the tests from
> t/pmc/thread.reast and t/pmc/timer.t but thread_4.pasm(don't know yet
> why it fails)

threads_4 is testing killing threads. This is achieved by scheduling a
terminate event to the running interpreter. This can only succeed, if
the event system is running too.
see src/events.c/Parrot_new_terinate_event()

> imcc.l.diff, imcc.y.diff et al - contain a dirty hack which prefixes the
> CONST lexeme with underscore, otherwise CONST conflicts with MACRO from
> windows header files. Probably the solution wwould be to prefix all the
> lexemes with IMCC_ or whatever. Prefixing should be done for thread
> primitives either.

Argh, yes. Can you just #undef the CONST after including the windows.h?

leo

Vladimir Lipsky

unread,
May 3, 2005, 1:59:18 AM5/3/05
to Leopold Toetsch, perl6-i...@perl.org
> threads_4 is testing killing threads. This is achieved by scheduling a
> terminate event to the running interpreter. This can only succeed, if the
> event system is running too.
> see src/events.c/Parrot_new_terinate_event()

Though thr_windows.h doesn't contain error checking for now, it luckily
fails when the killed thread returns from runops and tries to LOCK the
interpreter_array_mutex. But before that the thread of the main interp had
time to call Parrot_really_destroy, loop interpreter_array, and free
interpreter_array_mutex. Here I see two solutions:
A) do not free the array and mutex asscociated with it at all; those are
global, malloced once, have no destructor, would it be a memory leak?
B) the very last thread do the work, it iterates thru array and if all tids
are null(except itself), free array and mutex.

On the another hand I didnt see that interpreters task queues and mutexes of
the shared pmc's(sub and Interp, probably) were freed up anywhere. It's that
normal?

And on the third hand, if I understood the code correctly ...

src/threads.c: 40: thread_func()
src/threads.c: 53: interpreter->thread_data->state |= THREAD_STATE_FINISHED;

src/threads.c: 312: pt_thread_join ()
src/threads.c: 321: if (interpreter->thread_data->state ==
THREAD_STATE_JOINABLE ||
src/threads.c: 322: interpreter->thread_data->state ==
THREAD_STATE_FINISHED) {

src/threads.c: 453: detach()
src/threads.c: 462: if (interpreter->thread_data->state ==
THREAD_STATE_JOINABLE ||
src/threads.c: 463: interpreter->thread_data->state ==
THREAD_STATE_FINISHED) {

lines 322, 463 never hold true, because of line 53. So pt_thread_join,
detach are never able do their work on threads that have runops-ed.

> Argh, yes. Can you just #undef the CONST after including the windows.h?

Ok, done it.

win32_threads.patch

Leopold Toetsch

unread,
May 3, 2005, 4:21:56 AM5/3/05
to Vladimir Lipsky, perl6-i...@perl.org
Vladimir Lipsky wrote:
>> threads_4 is testing killing threads. This is achieved by scheduling a
>> terminate event to the running interpreter. This can only succeed, if
>> the event system is running too.
>> see src/events.c/Parrot_new_terinate_event()
>
>
> Though thr_windows.h doesn't contain error checking for now, it luckily
> fails when the killed thread returns from runops and tries to LOCK the
> interpreter_array_mutex. But before that the thread of the main interp
> had time to call Parrot_really_destroy, loop interpreter_array, and free
> interpreter_array_mutex.

This case can be considered as a programmers error (we should guard
against it if possible, though). When the "main" or first interpreter
terminates the packfile with the opcodes is destroyed. A still running
thread wouldn't have any more code to execute.

> ... Here I see two solutions:


> A) do not free the array and mutex asscociated with it at all; those are
> global, malloced once, have no destructor, would it be a memory leak?
> B) the very last thread do the work, it iterates thru array and if all
> tids are null(except itself), free array and mutex.

B) if any, but it's not only freeing the interpreter array. The last one
has to do all the work that the main interpreter should have done.

See also src/inter_create.c:Parrot_really_destroy()

> On the another hand I didnt see that interpreters task queues and
> mutexes of the shared pmc's(sub and Interp, probably) were freed up
> anywhere. It's that normal?

There are presumably some more leaks in the code, yes - err no ;-)

> And on the third hand, if I understood the code correctly ...
>
> src/threads.c: 40: thread_func()
> src/threads.c: 53: interpreter->thread_data->state |=
> THREAD_STATE_FINISHED;
>
> src/threads.c: 312: pt_thread_join ()
> src/threads.c: 321: if (interpreter->thread_data->state ==
> THREAD_STATE_JOINABLE ||
> src/threads.c: 322: interpreter->thread_data->state ==
> THREAD_STATE_FINISHED) {
>
> src/threads.c: 453: detach()
> src/threads.c: 462: if (interpreter->thread_data->state ==
> THREAD_STATE_JOINABLE ||
> src/threads.c: 463: interpreter->thread_data->state ==
> THREAD_STATE_FINISHED) {
>
> lines 322, 463 never hold true, because of line 53. So pt_thread_join,
> detach are never able do their work on threads that have runops-ed.

I don't think so: in line 47 the thread enters the runloop, state is
JOINABLE (except when created detached). Another thread, which has the
TID of the thread can now join or detach it. Only when the thread
leaves its runloop, it's state is set to FINISHED. So at e.g. line 322
it can be JOINABLE (still running) or FINISHED. The JOIN() then gets the
return result, which possibly causes the caller to wait for the thread
to finish.

>> Argh, yes. Can you just #undef the CONST after including the windows.h?
>
> Ok, done it.

Good.

Thanks, applied
leo

Vladimir Lipsky

unread,
May 3, 2005, 5:35:19 AM5/3/05
to Leopold Toetsch, perl6-i...@perl.org
>> And on the third hand, if I understood the code correctly ...
>>
>> src/threads.c: 40: thread_func()
>> src/threads.c: 53: interpreter->thread_data->state |=
>> THREAD_STATE_FINISHED;
>>
>> src/threads.c: 312: pt_thread_join ()
>> src/threads.c: 321: if (interpreter->thread_data->state ==
>> THREAD_STATE_JOINABLE ||
>> src/threads.c: 322: interpreter->thread_data->state ==
>> THREAD_STATE_FINISHED) {
>>
>> src/threads.c: 453: detach()
>> src/threads.c: 462: if (interpreter->thread_data->state ==
>> THREAD_STATE_JOINABLE ||
>> src/threads.c: 463: interpreter->thread_data->state ==
>> THREAD_STATE_FINISHED) {
>>
>> lines 322, 463 never hold true, because of line 53. So pt_thread_join,
>> detach are never able do their work on threads that have runops-ed.
>
> I don't think so: in line 47 the thread enters the runloop, state is
> JOINABLE (except when created detached). Another thread, which has the TID
> of the thread can now join or detach it. Only when the thread leaves its
> runloop, it's state is set to FINISHED. So at e.g. line 322

It's state is set to PREVIOUS_STATE+FINISHED
So it's never equal to just FINISHED

>> src/threads.c: 53: interpreter->thread_data->state |=
>> THREAD_STATE_FINISHED;

>> src/threads.c: 322: interpreter->thread_data->state ==
>> THREAD_STATE_FINISHED) {

Typo or what?

Leopold Toetsch

unread,
May 3, 2005, 6:13:45 AM5/3/05
to Vladimir Lipsky, perl6-i...@perl.org
Vladimir Lipsky wrote:

> It's state is set to PREVIOUS_STATE+FINISHED
> So it's never equal to just FINISHED

Ah, Yep. Works for JOINABLE, which is 0, but ...

> Typo or what?

Inexact ;-)

leo


Reply all
Reply to author
Forward
0 new messages