www.digitalmars.com         C & C++   DMDScript  

D - synchronize w/o signal & wait

reply "Jim Eberle" <jeberle1 my-deja.com> writes:
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
Aug 24 2001
parent reply "Walter" <walter digitalmars.com> writes:
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
Aug 25 2001
parent reply Dan Hursh <hursh infonet.isl.net> writes:
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
Aug 26 2001
parent reply "Walter" <walter digitalmars.com> writes:
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.
Aug 26 2001
parent reply 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
Aug 26 2001
next sibling parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
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
Aug 26 2001
next sibling parent reply "Walter" <walter digitalmars.com> writes:
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
Aug 27 2001
next sibling parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
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
Aug 27 2001
parent "Walter" <walter digitalmars.com> writes:
Russell Bornschlegel wrote in message <3B8A8D3D.BFB2D948 estarcion.com>...

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.



I don't believe I'm making an edifice that will not be easilly ported to
most unix systems. I've done some multithreaded work on linux, and I don't
see any hard problems.

I do know Win32 systems best, which is why I chose to make it the first
implementation.
Aug 28 2001
prev sibling parent reply Dan Hursh <hursh infonet.isl.net> writes:
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 -- 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.


	I guess I'm worried about what is 'suitable'.  Don't some threading
packages provide drastically different schemes for things like locking,
message passing, preemption, killing, etc.?  I can accept different
libraries on different platforms, but are we going to be in a position
were we say "The D way of locking is 'synchronize' but it's semantics
are platform dependent."  
	I like that D is standardizing locking, but I don't know that it will
be of much value if we don't go all the way and standardize how
threading behaves in D.  There can be sets of semantics that platforms
can optional choose as extensions.  Whatever.  I just don't like have
one standard piece in an otherwise amorphous puzzle.  I now can't choose
for myself, and I don't have a complete solution to the multi-threading
problem.

Dan
Aug 27 2001
parent "Walter" <walter digitalmars.com> writes:
Dan Hursh wrote in message <3B8ADBC6.F802047A infonet.isl.net>...

 I guess I'm worried about what is 'suitable'.  Don't some threading
packages provide drastically different schemes for things like locking,
message passing, preemption, killing, etc.?  I can accept different
libraries on different platforms, but are we going to be in a position
were we say "The D way of locking is 'synchronize' but it's semantics
are platform dependent."



I really don't understand. What is platform dependent about a mutex
interface? I've written mutexes for linux, Windows, OS/2, etc., and it never
was an issue.


 I like that D is standardizing locking, but I don't know that it will
be of much value if we don't go all the way and standardize how
threading behaves in D.  There can be sets of semantics that platforms
can optional choose as extensions.  Whatever.  I just don't like have
one standard piece in an otherwise amorphous puzzle.  I now can't choose
for myself, and I don't have a complete solution to the multi-threading
problem.



The synchronize addresses only one issue in multithreaded programming, but a
very commonly used one.
Aug 28 2001
prev sibling next sibling parent Kevin Quick <kevin.quick surgient.com> writes:
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
Aug 27 2001
prev sibling parent "Sean L. Palmer" <spalmer iname.com> writes:
I don't think a spinloop is going to be the most effective way to utilize a
machine's cycles.

Threading needs to be supported by the OS.

Sean


 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
Nov 05 2001
prev sibling parent Kevin Quick <kevin.quick surgient.com> writes:
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
Aug 27 2001