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

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.

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.

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