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