Newsgroups: comp.sys.transputer
From: ruthc@sharra.demon.co.uk (Ruth Ivimey-Cook)
Subject: Re: About virtual channels (2)
Organization: At Home
Date: Mon, 01 Jun 1998 19:33:36 GMT
Message-ID: <3572fd53.327349283@sharra.demon.co.uk>

On 28 May 1998 14:04:00 GMT, "Alberto Chessa" <achessa@fiar.finmeccanica.it>
wrote:

>What appends when one process is blocked on a ChanOut on a virtual channel
>and another process send another message on a virtual channel mapped on the
>same link ?
>The second process will block until the first one will terminate the
>transfer ?

I don't actually know the implementation involved in the SGS-T toolset.
However, many other implementations have been described (see several issues
of the WoTUG conference proceedings, abstracts available on the parallel
archive at HENSA: http://www.hensa.ac.uk/parallel/ ). For output. they
mostly use a single (usually high priority) process which can write to the
link directly which then ALTs over a set of soft channels which are not
shared. User proceses write to the soft channels, which block in a 'fair'
way to share the hard channel. Hence the answers to your questions are both
no.

Your first post asked about overheads. All virtual channel systems impost an
overhead; in the case of software driven ones it is significant: At least
two extra context switches and a memory copy are required. Many
implementations also demand that the data being sent over the channel obeys
some simple protocol (such as INT16::[]BYTE ) making the code less checkable
than would be the case if you let the occam compiler see the real
protocols..

Best regards,

Ruth