- GftThreads

From: Douglas G. Danforth <"Douglas>
Date: Mon, 25 Apr 2005 13:53:12 -0400

----boundary-LibPST-iamunique-391380553_-_-
Content-type: text/plain

Folks,
I have implemented a module GftThreads that works for simple tasks and
operates in nanosecond response times (16ns on my machine).
The simple interface (patterned a little after Services.Action) looks like.

DEFINITION GftThreads;

   TYPE
     Action = POINTER TO ABSTRACT RECORD
       (a: Action) Do, NEW, ABSTRACT;
       (a: Action) Start, NEW;
       (a: Action) Stop, NEW
     END;

END GftThreads.

Calling action.Start puts the function action.Do into a tight loop
running in a child thread. Calling action.Stop from the parent
terminates this loop and the thread. The child shares the memory space
of the parent.

However, I am getting in over my head. The functions that the user
places in action.Do must be 'thread-safe'. Neither Out.String, nor
XYplane.Dot seem to satisfy the 'thread-safe' condition. They both work
  for a single Start-Stop pair but a second Start causes the system to
hang (for Out there seems to be an interaction with the routines that
write to the log and preconditions are violated).

I would like the user not have to worry about 'thread-safety' and so
believe something like critical regions are necessary.

Does anyone have experience with Windows' threads that could give some
pointers?

-Doug

--- BlackBox
--- send subject HELP or UNSUBSCRIBE to blackbox{([at]})nowhere.xy



----boundary-LibPST-iamunique-391380553_-_-
Content-type: application/rtf
Content-transfer-encoding: base64
Content-Disposition: attachment; filename="rtf-body.rtf"

e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZnJvbXRleHQgXGRlZmYwe1xmb250dGJsDQp7XGYwXGZz
d2lzcyBBcmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291cmllciBOZXc7fQ0Ke1xmMlxmbmlsXGZjaGFy
c2V0MiBTeW1ib2w7fQ0Ke1xmM1xmbW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyIE5ldzt9fQ0Ke1xj
b2xvcnRibFxyZWQwXGdyZWVuMFxibHVlMDtccmVkMFxncmVlbjBcYmx1ZTI1NTt9DQpcdWMxXHBh
cmRccGxhaW5cZGVmdGFiMzYwIFxmMFxmczIwIEZvbGtzLFxwYXINCkkgaGF2ZSBpbXBsZW1lbnRl
ZCBhIG1vZHVsZSBHZnRUaHJlYWRzIHRoYXQgd29ya3MgZm9yIHNpbXBsZSB0YXNrcyBhbmQgXHBh
cg0Kb3BlcmF0ZXMgaW4gbmFub3NlY29uZCByZXNwb25zZSB0aW1lcyAoMTZucyBvbiBteSBtYWNo
aW5lKS5ccGFyDQpUaGUgc2ltcGxlIGludGVyZmFjZSAocGF0dGVybmVkIGEgbGl0dGxlIGFmdGVy
IFNlcnZpY2VzLkFjdGlvbikgbG9va3MgbGlrZS5ccGFyDQpccGFyDQpERUZJTklUSU9OIEdmdFRo
cmVhZHM7XHBhcg0KXHBhcg0KICAgVFlQRVxwYXINCiAgICAgQWN0aW9uID0gUE9JTlRFUiBUTyBB
QlNUUkFDVCBSRUNPUkRccGFyDQogICAgICAgKGE6IEFjdGlvbikgRG8sIE5FVywgQUJTVFJBQ1Q7
XHBhcg0KICAgICAgIChhOiBBY3Rpb24pIFN0YXJ0LCBORVc7XHBhcg0KICAgICAgIChhOiBBY3Rp
b24pIFN0b3AsIE5FV1xwYXINCiAgICAgRU5EO1xwYXINClxwYXINCkVORCBHZnRUaHJlYWRzLlxw
YXINClxwYXINCkNhbGxpbmcgYWN0aW9uLlN0YXJ0IHB1dHMgdGhlIGZ1bmN0aW9uIGFjdGlvbi5E
byBpbnRvIGEgdGlnaHQgbG9vcCBccGFyDQpydW5uaW5nIGluIGEgY2hpbGQgdGhyZWFkLiBDYWxs
aW5nIGFjdGlvbi5TdG9wIGZyb20gdGhlIHBhcmVudCBccGFyDQp0ZXJtaW5hdGVzIHRoaXMgbG9v
cCBhbmQgdGhlIHRocmVhZC4gIFRoZSBjaGlsZCBzaGFyZXMgdGhlIG1lbW9yeSBzcGFjZSBccGFy
DQpvZiB0aGUgcGFyZW50LlxwYXINClxwYXINCkhvd2V2ZXIsIEkgYW0gZ2V0dGluZyBpbiBvdmVy
IG15IGhlYWQuICBUaGUgZnVuY3Rpb25zIHRoYXQgdGhlIHVzZXIgXHBhcg0KcGxhY2VzIGluIGFj
dGlvbi5EbyBtdXN0IGJlICd0aHJlYWQtc2FmZScuICBOZWl0aGVyIE91dC5TdHJpbmcsIG5vciBc
cGFyDQpYWXBsYW5lLkRvdCBzZWVtIHRvIHNhdGlzZnkgdGhlICd0aHJlYWQtc2FmZScgY29uZGl0
aW9uLiAgVGhleSBib3RoIHdvcmsgXHBhcg0KICBmb3IgYSBzaW5nbGUgU3RhcnQtU3RvcCBwYWly
IGJ1dCBhIHNlY29uZCBTdGFydCBjYXVzZXMgdGhlIHN5c3RlbSB0byBccGFyDQpoYW5nIChmb3Ig
T3V0IHRoZXJlIHNlZW1zIHRvIGJlIGFuIGludGVyYWN0aW9uIHdpdGggdGhlIHJvdXRpbmVzIHRo
YXQgXHBhcg0Kd3JpdGUgdG8gdGhlIGxvZyBhbmQgcHJlY29uZGl0aW9ucyBhcmUgdmlvbGF0ZWQp
LlxwYXINClxwYXINCkkgd291bGQgbGlrZSB0aGUgdXNlciBub3QgaGF2ZSB0byB3b3JyeSBhYm91
dCAndGhyZWFkLXNhZmV0eScgYW5kIHNvIFxwYXINCmJlbGlldmUgc29tZXRoaW5nIGxpa2UgY3Jp
dGljYWwgcmVnaW9ucyBhcmUgbmVjZXNzYXJ5LlxwYXINClxwYXINCkRvZXMgYW55b25lIGhhdmUg
ZXhwZXJpZW5jZSB3aXRoIFdpbmRvd3MnIHRocmVhZHMgdGhhdCBjb3VsZCBnaXZlIHNvbWUgXHBh
cg0KcG9pbnRlcnM/XHBhcg0KXHBhcg0KLURvdWdccGFyDQpccGFyDQotLS0gQmxhY2tCb3hccGFy
DQotLS0gc2VuZCBzdWJqZWN0IEhFTFAgb3IgVU5TVUJTQ1JJQkUgdG8gYmxhY2tib3hAb2Jlcm9u
LmNofX0ALjAKQ29udGVudA==


----boundary-LibPST-iamunique-391380553_-_---
Received on Mon Apr 25 2005 - 19:53:12 UTC

This archive was generated by hypermail 2.3.0 : Thu Sep 26 2013 - 06:28:16 UTC