Am I missing something here? Providing synchronize w/o signal/wait seems to leave out half of the typical MT semantics.

IMHO, I think dedicated classes for Mutex's & ConditionVariables (like in the ACE C++ library and Ruby) are a better way to package the functionality v. tacking it on to the Object base class (like in D & Java). Why make _every_ instance provide MT methods?

Jim

It consumes 4 bytes per object to provide this functionality. -Walter

Jim Eberle wrote in message <9m64qi$2ml6$1@digitaldaemon.com>...
>Am I missing something here? Providing synchronize w/o signal/wait seems to leave out half of the typical MT semantics.
>
>IMHO, I think dedicated classes for Mutex's & ConditionVariables (like in
the
>ACE C++ library and Ruby) are a better way to package the functionality v. tacking it on to the Object base class (like in D & Java). Why make _every_ instance provide MT methods?
>
>Jim
>
>
>

Walter wrote:
> 
> It consumes 4 bytes per object to provide this functionality. -Walter
> 
> Jim Eberle wrote in message <9m64qi$2ml6$1@digitaldaemon.com>...
> >Am I missing something here? Providing synchronize w/o signal/wait seems to leave out half of the typical MT semantics.
> >
> >IMHO, I think dedicated classes for Mutex's & ConditionVariables (like in
> the
> >ACE C++ library and Ruby) are a better way to package the functionality v. tacking it on to the Object base class (like in D & Java). Why make _every_ instance provide MT methods?


	In this vein, synchronize is in the language, but the mechanism for
spawninga thread isn't.  I'm guessing you either didn't get that far, or
you want to put it in the library.  If you are planning the library
route, than that could be a problem.
	With threading just in the library on just in the language, the
implemntation details are all in one place.  Splitting the two could be
a maintenance issue.  In the end I guess I don't care if it works when I
use it.  But it could be the source of some interesting configuration
errors.

Dan

Dan Hursh wrote in message <3B88ABD9.EF4541F5@infonet.isl.net>...
> In this vein, synchronize is in the language, but the mechanism for
>spawninga thread isn't.  I'm guessing you either didn't get that far, or you want to put it in the library.  If you are planning the library route, than that could be a problem.
> With threading just in the library on just in the language, the
>implemntation details are all in one place.  Splitting the two could be a maintenance issue.  In the end I guess I don't care if it works when I use it.  But it could be the source of some interesting configuration errors.


I'm planning on threading being in the library.

Walter wrote:
> 
> Dan Hursh wrote in message <3B88ABD9.EF4541F5@infonet.isl.net>...
> > In this vein, synchronize is in the language, but the mechanism for
> >spawninga thread isn't.  I'm guessing you either didn't get that far, or you want to put it in the library.  If you are planning the library route, than that could be a problem.
> > With threading just in the library on just in the language, the
> >implemntation details are all in one place.  Splitting the two could be a maintenance issue.  In the end I guess I don't care if it works when I use it.  But it could be the source of some interesting configuration errors.
> 
> I'm planning on threading being in the library.

	Would synchronize call hooks in the library, or am I artificially
linking threading and synchronization together?  I will admit that I
think the library is the best place for it.  Distribution binaries might
get difficult if there are configurable options for threading packages
on a given platform.  It might be a good place for someone to crack a
whip.

Dan

Dan Hursh wrote:
> 
> Walter wrote:
> >
> > Dan Hursh wrote in message <3B88ABD9.EF4541F5@infonet.isl.net>...
> > > In this vein, synchronize is in the language, but the mechanism for
> > >spawninga thread isn't.  [...snip...]
>
> > I'm planning on threading being in the library.
> 
>         Would synchronize call hooks in the library, or am I artificially
> linking threading and synchronization together?

If I'm not completely mistaken, synchronize is easy enough to implement without knowing about the OS -- the compiler just has to statically allocate a byte or an int and do a test-and-set spinloop at the start of the the synch block and a clear at the end of the block. Thus it's lightweight, doesn't need a function call, and it's instruction-set-specific (rather than OS-specific), which makes it a good candidate for being the compiler's responsibility.

As the spec stands, I think you could wrap the C/Win32 CreateThread (for example) and use it successfully with the D synchronize{}.

-RB

Russell Bornschlegel wrote in message <3B89E955.CD662B00@estarcion.com>...
>If I'm not completely mistaken, synchronize is easy enough to
>implement without knowing about the OS -- the compiler just has to
>statically allocate a byte or an int and do a test-and-set spinloop
>at the start of the the synch block and a clear at the
>end of the block. Thus it's lightweight, doesn't need a function
>call, and it's instruction-set-specific (rather than OS-specific),
>which makes it a good candidate for being the compiler's
>responsibility.


Spin locks suffer from terrible performance problems. In any case, I just don't believe that any operating system offering multithreaded programming isn't going to offer a suitable locking primitive.

-Walter

Russell Bornschlegel <kaleja@estarcion.com> writes:

> If I'm not completely mistaken, synchronize is easy enough to implement without knowing about the OS -- the compiler just has to statically allocate a byte or an int and do a test-and-set spinloop at the start of the the synch block and a clear at the end of the block. Thus it's lightweight, doesn't need a function call, and it's instruction-set-specific (rather than OS-specific), which makes it a good candidate for being the compiler's responsibility.

This is usually the basis for thread-based mutex operations, but it doesn't provide quite enough in and of itself.

The problem is that when your thread is merrily executing and hits this test-and-set spinloop without having ownership, it will happily eat the CPU alive even though the flag just told it that there wasn't anything it was supposed to be doing.  This will continue until the system clock interrupts it and the system scheduler decides your thread's current processing time quantum is used up; the thread will be moved to the back of the scheduler queue (relative to priority) and *hopefully* the scheduler will now run the thread that does hold the lock.  However, that thread's processing to eventual release of the lock keeps getting interrupted by the scheduler running the spinning thread... which is "runnable" although it doesn't really have anything to do.

A mutex acquisition is really a scheduling point where the ownership is attempted and, upon failure, the thread is placed on a "waiting" queue relative to that mutex and is moved *out* of the active scheduling loop.  Often, the thread holding the mutex is immediately scheduled.

-Kevin

Dan Hursh <hursh@infonet.isl.net> writes:

> Walter wrote:
> > 
> > Dan Hursh wrote in message <3B88ABD9.EF4541F5@infonet.isl.net>...
> > > In this vein, synchronize is in the language, but the mechanism for
> > >spawninga thread isn't.  I'm guessing you either didn't get that far, or you want to put it in the library.  If you are planning the library route, than that could be a problem.
> > > With threading just in the library on just in the language, the
> > >implemntation details are all in one place.  Splitting the two could be a maintenance issue.  In the end I guess I don't care if it works when I use it.  But it could be the source of some interesting configuration errors.
> > 
> > I'm planning on threading being in the library.
> 
> 	Would synchronize call hooks in the library, or am I artificially
> linking threading and synchronization together?  I will admit that I
> think the library is the best place for it.  Distribution binaries might
> get difficult if there are configurable options for threading packages
> on a given platform.  It might be a good place for someone to crack a
> whip.
> 
> Dan

Interesting parallel to the newsthread Re: synchronize issues...

Threading being in "the" library is fine, but it must be fully specified and the synchronize statement should probably indicate that it uses the library's threading (for implementer's, at least).

One problem with standardized threading in D is that the both the semantics and implementation are locked-down; alternate threading packages cannot be tried.

One way to resolve most of the issues is to define synchronize statement as calling the thread-library's mutex statement, and by providing a way to link against a different thread-library (providing the same API) rather than the standard one.

-Kevin

Walter wrote:
> 
> Russell Bornschlegel wrote in message <3B89E955.CD662B00@estarcion.com>...
> >If I'm not completely mistaken, synchronize is easy enough to implement without knowing about the OS --
>
> Spin locks suffer from terrible performance problems.

D'oh! Don't ask me what the hell I was thinking. The big picture was just temporarily swapped out of my working set or something.

> In any case, I just
> don't believe that any operating system offering multithreaded programming
> isn't going to offer a suitable locking primitive.

Well, as I understand it, Mr. Quick is concerned about those platforms which offer multiple thread implementations.

Question One: Do the various threading systems found on the Unixoid systems (pthreads and ssthreads were mentioned) use identical or compatible locking schemes?

If yes, then no problem - we pick the locking scheme that supports a majority of multithreaded programming on the Unixoids and say that's all the officially supported threading systems.

If no, then Question Two: Do we define one particular threading system as D's one true threading system on the Unixoids, and let the chips fall where they may, or do we add an option to the compiler?

These questions are incredibly loaded via use of the term 'we' -- Walter seems to be mainly concerned with getting it to work on Win32, where he already knows the answers to threading and synching; he can certainly make this Someone Else's Problem.

_RB