[Mono-list] Threading/Synchronization and the System.Thread namespace

Pablo Castro caster@lagash.com
Fri, 13 Jul 2001 01:15:58 -0300


I'd like to contribute the bunch of classes in the System.Thread namespace.
I have some hardcore experience in writing multi-threaded applications both
in Windows and Unix so I think I can do a good work here. Anyone is already
working on this? (I wouldn't like to end up with to implementation for the
same stuff...)

Now, this namespace is somehow special in that it deals with threading,
which is something that the JIT should control (at least, thread creation
(stack and stuff), we cannot just P/Invoke pthread_create :).

So, here are some first-thought issues I'd like to share and get some
opinions:

.All the synchronization stuff can be implemented by just wrapping the
pthread functions for mutexes and condition variables. They need to be
converted to "Microsoft-styled threading", but this is not a major issue. A
first implementation would just do its work...further optimization can be
done later, as the MS implementation does (i.e. event and mutex handle
pooling).

.One exception is the Monitor mechanism. I'm not sure, but I think that the
JIT/VES needs to be aware about object monitors. May be we would need some
coordination with the compiler/JIT/VES writers (Paolo, Miguel ??)

.Thread operations (init, pause, join, etc) need to be coordinated with the
JIT compiler. The GC also gets in middle (i.e. for thread hijacking and safe
points). This also needs some hints from JIT/VES writers, as well as GC
writers.

.Although using P/Invoke to wrap the posix thread library seems to be a good
option, it may complicate a port to non-unix/posix OS like Windows, which
have its own threading API. (ok, you could use MS.NET in Windows, but...)

After we get some consensus about this, I'll be able to start writing the
System.Thread classes (those that are mostly bindings). Thread creation and
management will probably need some work on the JIT side, thus it will take
longer to start (some form of the JIT itself have to exist first :)

Ideas are welcome.

Pablo Castro
Lagash Systems