No subject

would at least be potentially portable to other POSIX systems.

>> 
>>     The following comments from previous posts obviously indicate a problem
>> here.  So what is a ( or should I say THE ) suggested replacement method
for
>> yield?
>
>IMNSHO, using yield is *rarely* the right solution to any problem.  One
>could also argue that thread priorities is also a bad solution as wel,
>and I won't argue against it. :)
>
>> sleep() is an obvious one, but choosing an efficient time certainly
>> eludes me.  wait/notify certainly tells me when another thread is done, but
>> if I have 50 threads, where am I?  Back to using my own mutex or something?
>
>As Doug Lea's book points out very well, any significant problem that
>involve multiple threads *will* involve the writer using something other
>than the basic wait/notify capabilities of java.  Either download Doug's
>stuff, or roll your own where his stuff is either inadequate.
>
I'm afraid I agree. As John Ousterhout argued at the 1996 USENIX technical
conference 'Threads Are A Bad Idea (for most purposes)'. He advocates using
event based programming, which often accomplishes the same thing whilst
being much easier to code. (see
http://www.scriptics.com/people/john.ousterhout/threads.ppt)

>However, the point is that code built on wait/notify provides a much
>more robust solution to the scheduling problem.
>
robust != portable. 

>>     Since built in threading capability is one of java's touted strengths,
>> API methods should be reliable.
>
>They are *EXTREMELY* reliable, but they aren't complete.  Partly because
>there is no way (IMO) they could be implemented as a complete solution
>for every situation.
>
>For example, let's assume you need a reader/writer implementation.  In
>your implementation, is the order of readers/writers into the system
>important.  Do writers have priority over readers, or vice-versa?  Is
>there an upper-limit on the number of readers that are allowed before a
>writer gets a chance at it?  Anyway, there are *hundreds* of different
>ways of resolving scheduling conflicts in this one example, so any
>solution that Sun or anyone else provides won't be adequate for every
>situation.
>
>But, every solution *can* be implemented with the simple scheduling
>objects provided in wait/notify and join.  Sun has provided all you need
>to do your job, but it hasn't done your job for you.
>
Quite so.



Charles Stewart
Chief Technology Officer
World-wide Intellectual Resources Exchange (WIRE) Ltd.
Sussex Innovation Centre
Brighton BN1 9SB
United Kingdom

E-mail: charles at wire.co.uk
Tel: +44 (0) 1273 704414
Fax: +44 (0) 1273 704416
Web: http://wire.co.uk/
PGP key ID: Diffie-Hellman/DSS: 0xC808D6B1

---
To unsubscribe, mail advanced-java-unsubscribe at xcf.berkeley.edu
To get help, mail advanced-java-help at xcf.berkeley.edu