[MUD-Dev] Re: lurker emerges

[Vadim Tkachenko]

[Funny, I didn't see my post, but see yours???]

T. Alexander Popiel wrote:
> 
> In message:  <35CFBD79.68748E69 at freehold.crocodile.org>
>              Vadim Tkachenko <vt at freehold.crocodile.org> writes:

[skipped]

> >ACT is the Asynchronous Completion Token (Design patterns...), has
> >read_count field and a semaphore.
> >
> >ACT    asyncread( buffer, how_much_do_I_want, boolean all_async );
> >
> >OK, so what I have is some read performed at once (no sense in async
> >read if I know the absolute minimum I want), and then I know how much
> >did I read - the ACT has it. Then, I can go out and do my stuff, and
> >when I'm ready I may go out and wait for the completion semaphore (let
> >me emphasise, _event_ semaphore).
> 
> If I'm reading this correctly, your asyncread() creates a semaphore,
> spawns a thread, associates the two, and returns immediately.  The
> spawned thread does the actual blocking read, then notifies the
> semaphore and exits.
> 
> To recreate my non-blocking I/O library call, you've added the
> overhead of semaphore creation and destruction (and a possible
> semaphore leak if the caller does not dispose of the semaphore
> properly), and thread creation and destruction, all to end up
> with something functionally equivalent to what I wanted in the
> first place.

The keyword here is "functionally equivalent".

>  Personally, I don't see this as a win.

Neither do I, but what's important to me is a portability. Can you agree
that you can encapsulate all this stuff so whatever the implementation
is you can keep the interface the same? And, this way or that, using
semaphores as a standard way of event notification really helps to keep
the logical structure consistent. Actually, the semaphores I use in Java
are neither the underlying OS semaphores nor Java semaphores (they don't
exist there), but something I made up - they're [hopefully] lighter than
actual OS ones.

> Especially on systems (like SunOS 4.1.3) which don't support threading at
> all, making what you suggest well nigh impossible.

I see your point, but since I've been trying to program the parallel
stuff in DOS and Windows and then came to multithreaded OS/2 (it was
before I saw a first live UNIX box), I vowed not to use
non-multithreaded systems for parallel system development. This is my
personal preference, nothing more.

> >So, on the API level - what's the difference between the _library_ call
> >and the simple piece of code I'm talking about? Agreed, the former may
> >be _much_ more effective, but if you're going to production, you need
> >the _scalable_ solution anyway, and if it really bothers you, go to the
> >platform which does have the stuff you mentioned and make it native, in
> >Java case.
> 
> I think the only difference is in performance and the a stylistic
> preference in choice of primitives.  I prefer async primitives,

I _use_ them, too, but on the higher level - usually, I use the blocking
read/write below the readObject/writeObject level, and sems and threads
above

> because sync can be built on async with trivial performance loss
> (two routine calls (request, wait) instead of one),

It may be Java-specific, but what really annoys me is a variety of ways
to tell me what was the result of async operation - some return -1, some
null, some throw exception... Please remind me, how do you wait in the
programming environment which doesn't have the synchronized methods like
Java does? I remember, in OS/2 I was using the threads and mutexes
anyway, maybe some async operations were supporting the callback
routines, which is not elegant anyway... What am I missing here?

> while async can be built on sync only with lots of other cruft (semaphores,
> threads)

This may be arguable, but I (1) consider the semaphores a standard and
reusable way to communicate between event producers and consumers
(mutexes for locking, not actually applicable in Java) (2) consider the
multi-threading the more _logical_ architecture than the single-threaded
one. I usually sacrifice performance for clarity, - you can always
optimize the code later, but if you make your system consisting of small
patches here and there, nothing will help to prevent it from falling
apart.

> and large performance loss.

Depending on where you draw the line between the sync and async. Mine is
pretty high.

> >> The most important distinction in my mind is the ability (or
> >> lack thereof) to separate the request and the wait for request
> >> completion.
> >
> >Nah, the Asynchronous Completion Token is a solution in this case.
> 
> A solution which only works if you have a multithreaded environment...
> which I don't.  :-(

See above.

> - Alex

--
Still alive and smile stays on,
Vadim Tkachenko <vt at freehold.crocodile.org>
--
UNIX _is_ user friendly, he's just very picky about who his friends are