Consider passing a value as "inout" parameter to a function.
Then both the caller and the called functions continue to use the same
value, by multithreading.
Now when will the changes of the inout parameter be incorporated into the
original variable?
Immediately, or when the called function returns?
The specification does not tell. (Walter: please put it in)
The "inout" name suggests the later, but the first happens (i hope).
Therefore the name "inout" is not really intuitive. I would rather suggest
"ref", because what is happening is passing a parameter by reference.

Sandor

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:angu34$4ba$1@digitaldaemon.com...
> Consider passing a value as "inout" parameter to a function.
> Then both the caller and the called functions continue to use the same
> value, by multithreading.
> Now when will the changes of the inout parameter be incorporated into the
> original variable?
> Immediately, or when the called function returns?

When the called function sets it to a value. I'm not sure why it matters.

> The specification does not tell. (Walter: please put it in)
> The "inout" name suggests the later, but the first happens (i hope).
> Therefore the name "inout" is not really intuitive. I would rather suggest
> "ref", because what is happening is passing a parameter by reference.

True, but I like the consistency with "in" and "out" parameters.

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:angu34$4ba$1@digitaldaemon.com...
> Consider passing a value as "inout" parameter to a function.
> Then both the caller and the called functions continue to use the same
> value, by multithreading.
> Now when will the changes of the inout parameter be incorporated into the
> original variable?

Um, no.  The caller and called function do not both execute concurrently by multithreading.  It's just a function call.  (If you like, the caller is "suspended" until the called function returns - but it's definitely not as formal as that.)

> Immediately, or when the called function returns?
> The specification does not tell. (Walter: please put it in)
> The "inout" name suggests the later, but the first happens (i hope).
> Therefore the name "inout" is not really intuitive. I would rather suggest
> "ref", because what is happening is passing a parameter by reference.

It's enough to say that the adjusted value of any "inout" parameters are visible when the function returns.  The caller can't tell exactly when it happens (and indeed it doesn't matter) because it's not running.

In article <anhbkc$iah$1@digitaldaemon.com>, Richard Krehbiel says...
>
>"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:angu34$4ba$1@digitaldaemon.com...
>> Consider passing a value as "inout" parameter to a function.
>> Then both the caller and the called functions continue to use the same
>> value, by multithreading.
>> Now when will the changes of the inout parameter be incorporated into the
>> original variable?
>
>Um, no.  The caller and called function do not both execute concurrently by multithreading.  It's just a function call.  (If you like, the caller is
"suspended" until the called function returns - but it's definitely not as
>formal as that.)
>
>> Immediately, or when the called function returns?
>> The specification does not tell. (Walter: please put it in)
>> The "inout" name suggests the later, but the first happens (i hope).
>> Therefore the name "inout" is not really intuitive. I would rather suggest
>> "ref", because what is happening is passing a parameter by reference.
>
>It's enough to say that the adjusted value of any "inout" parameters are visible when the function returns.  The caller can't tell exactly when it happens (and indeed it doesn't matter) because it's not running.

Say the code has an array, then it creates two threads, and each of those threads calls a function, passing the single array through an inout array parameter.  You now have two threads of execution, each of which is accessing something that is nominally the same array.  The difference between "pass by reference" and "pass by copy/copyback" will be very obvious here.  If the functions accepted the array by reference, then each thread will be able to immediately see changes being made to the array by the other thread (to within register caching or optimization limits -- I think array lookups count as pointer accesses and disable optimization, so we'll ignore this possibility for now).  If the functions received a copy of the array, and will then copy their results back over the original array when they exit, then neither thread will see the work being done by the other thread (and race conditions are quite entertaining, since the first thread to return from this function call will have all of its results overwritten by the slower thread).  If you are taking a large problem array and slicing it into multiple threads to take advantage of SMP, you will probably pass the entire array to each thread, along with parameters to specify which part of the problem that thread should be working on.  Such a design will work with "pass by reference", but will fail completely with "pass by copy/copyback".  I always assumed that "inout" parameters (arrays or otherwise) were passed by reference, purely from a performance standpoint. "pass by copy/copyback" hasn't really been used (to my knowledge) in a long time.

I prefer pass by reference, both for performance and for correctness.  I agree that it should be documented, since it can make a very real difference, in very real programming problems.  I don't have a major problem with inout.  You might consider using "alias" instead, since you already have "alias" as a way to represent one variable/expression under a different name, which is exactly what an inout parameter does (it aliases the actual parameter under the formal parameter name.  Hopefully I got my ComSci terms correct there ;-).  I'm not sure which side of the "one syntax == one semantics" argument this "alias" usage would fall on.  I could argue it either way myself.

Anyway, change or don't change as you see necessary.  Definitely document exactly what it does.

And always remember that multithreading changes almost everything about any statement along the lines of "it doesn't matter, because it is equivalent behavior whether it is executed at point A or at point B".  And true SMP machines cause even more confusion, since they can actually mess with shared memory in the middle of a single instruction (if the instruction is "complicated" enough, usually meaning that it involves more than one memory access).

Food for thought,
Mac

"Mac Reiter" <Mac_member@pathlink.com> wrote in message news:anhn8t$u1o$1@digitaldaemon.com...
> In article <anhbkc$iah$1@digitaldaemon.com>, Richard Krehbiel says...
> >
> >"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:angu34$4ba$1@digitaldaemon.com...
> >> Consider passing a value as "inout" parameter to a function.
> >> Then both the caller and the called functions continue to use the same
> >> value, by multithreading.
> >> Now when will the changes of the inout parameter be incorporated into
the
> >> original variable?
> >
> >Um, no.  The caller and called function do not both execute concurrently
by
> >multithreading.  It's just a function call.  (If you like, the caller is
> "suspended" until the called function returns - but it's definitely not as
> >formal as that.)
> >
> >> Immediately, or when the called function returns?
> >> The specification does not tell. (Walter: please put it in)
> >> The "inout" name suggests the later, but the first happens (i hope).
> >> Therefore the name "inout" is not really intuitive. I would rather
suggest
> >> "ref", because what is happening is passing a parameter by reference.
> >
> >It's enough to say that the adjusted value of any "inout" parameters are visible when the function returns.  The caller can't tell exactly when it happens (and indeed it doesn't matter) because it's not running.
>
> Say the code has an array, then it creates two threads, and each of those threads calls a function, passing the single array through an inout array parameter.  You now have two threads of execution, each of which is
accessing
> something that is nominally the same array.  The difference between "pass
by
> reference" and "pass by copy/copyback"

I'm not sure that considering "pass by copy/copyback" is worth worrying
about
AFAIK only very old fortran compiler use this instead of  "pass by
reference" or "pass by address"
many languages, Perl for instance allows arrays to be "pass by copy", but no
write back
and C++ allows objects to be "pass by copy" again no write back.

I agree with the original post that 'inout' should be 'ref' or 'byref' and also think that for arrays you should have 'byval' when you want to pass a copy (that is not copy/writeback) just copy.

however I have started to become conserned about Walters comments somewhere else about arrays supporting copy-on-write operations.

if two threads have a reference to an array, one modifies the array, will the other ALWAYS see the modifications or will it possibly see the old array ?

 Mike.

Sorry.  No new info here.  But when I did my original reply, something wiped out the subject line, so my reply ended up just "Re:", and then a reply to that became "Re: Re:".  That didn't seem terribly useful to me, so I wanted to fix the subject line for further threading...

Mac

In article <anhq2l$12k2$1@digitaldaemon.com>, Mike Wynn says...
>
>
>"Mac Reiter" <Mac_member@pathlink.com> wrote in message news:anhn8t$u1o$1@digitaldaemon.com...
>> In article <anhbkc$iah$1@digitaldaemon.com>, Richard Krehbiel says...
>> >
>> >"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:angu34$4ba$1@digitaldaemon.com...
>> >> Consider passing a value as "inout" parameter to a function.
>> >> Then both the caller and the called functions continue to use the same
>> >> value, by multithreading.
>> >> Now when will the changes of the inout parameter be incorporated into
>the
>> >> original variable?
>> >
>> >Um, no.  The caller and called function do not both execute concurrently
>by
>> >multithreading.  It's just a function call.  (If you like, the caller is
>> "suspended" until the called function returns - but it's definitely not as
>> >formal as that.)
>> >
>> >> Immediately, or when the called function returns?
>> >> The specification does not tell. (Walter: please put it in)
>> >> The "inout" name suggests the later, but the first happens (i hope).
>> >> Therefore the name "inout" is not really intuitive. I would rather
>suggest
>> >> "ref", because what is happening is passing a parameter by reference.
>> >
>> >It's enough to say that the adjusted value of any "inout" parameters are visible when the function returns.  The caller can't tell exactly when it happens (and indeed it doesn't matter) because it's not running.
>>
>> Say the code has an array, then it creates two threads, and each of those threads calls a function, passing the single array through an inout array parameter.  You now have two threads of execution, each of which is
>accessing
>> something that is nominally the same array.  The difference between "pass
>by
>> reference" and "pass by copy/copyback"
>
>I'm not sure that considering "pass by copy/copyback" is worth worrying
>about
>AFAIK only very old fortran compiler use this instead of  "pass by
>reference" or "pass by address"
>many languages, Perl for instance allows arrays to be "pass by copy", but no
>write back
>and C++ allows objects to be "pass by copy" again no write back.
>
>I agree with the original post that 'inout' should be 'ref' or 'byref' and also think that for arrays you should have 'byval' when you want to pass a copy (that is not copy/writeback) just copy.
>
>however I have started to become conserned about Walters comments somewhere else about arrays supporting copy-on-write operations.
>
>if two threads have a reference to an array, one modifies the array, will the other ALWAYS see the modifications or will it possibly see the old array ?
>
> Mike.
>
>

>In article <anhq2l$12k2$1@digitaldaemon.com>, Mike Wynn says...
>>"Mac Reiter" <Mac_member@pathlink.com> wrote in message news:anhn8t$u1o$1@digitaldaemon.com...
>>> In article <anhbkc$iah$1@digitaldaemon.com>, Richard Krehbiel says...
>>> >"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:angu34$4ba$1@digitaldaemon.com...
>>> >> Consider passing a value as "inout" parameter to a function.
>>> >> Then both the caller and the called functions continue to use the same
>>> >> value, by multithreading.
>>> >> Now when will the changes of the inout parameter be incorporated into
>>the
>>> >> original variable?
>>> >
>>> >Um, no.  The caller and called function do not both execute concurrently
>>by
>>> >multithreading.  It's just a function call.  (If you like, the caller is
>>> "suspended" until the called function returns - but it's definitely not as
>>> >formal as that.)
>>> >
>>> >> Immediately, or when the called function returns?
>>> >> The specification does not tell. (Walter: please put it in)
>>> >> The "inout" name suggests the later, but the first happens (i hope).
>>> >> Therefore the name "inout" is not really intuitive. I would rather
>>suggest
>>> >> "ref", because what is happening is passing a parameter by reference.
>>> >
>>> >It's enough to say that the adjusted value of any "inout" parameters are visible when the function returns.  The caller can't tell exactly when it happens (and indeed it doesn't matter) because it's not running.
>>>
>>> Say the code has an array, then it creates two threads, and each of those threads calls a function, passing the single array through an inout array parameter.  You now have two threads of execution, each of which is
>>accessing
>>> something that is nominally the same array.  The difference between "pass
>>by
>>> reference" and "pass by copy/copyback"
>>
>>I'm not sure that considering "pass by copy/copyback" is worth worrying
>>about
>>AFAIK only very old fortran compiler use this instead of  "pass by
>>reference" or "pass by address"
>>many languages, Perl for instance allows arrays to be "pass by copy", but no
>>write back
>>and C++ allows objects to be "pass by copy" again no write back.

I have recently been informed by one of my coworkers that Windows device driver development does make use of the copy/copyback.  It is not always used, but there are situations where it is, and apparently they happen frequently enough to be built into the tools.  Since D is meant to be a systems programming language, I suspect that similar issues will arise.

While I could make the argument that "inout" would be good for copy/copyback and "ref" or "alias" would be good for referencing, I dislike that from the "what will the average person do?" standpoint.  The average user, seeing "in" and "out" will think of "inout" first.  That means that (if "inout" is kept at all) it should behave the way most people need it to, which is fast by reference. Another word like "copyinout" might be more explicit (and less likely for a novice to choose).  As before, I don't have a strong preference between "inout", "ref", and "alias" for the more common reference case.

Boy, did we wander a long way from the simple "request for documentation clarification" that started this thread...

Mac

>
> I have recently been informed by one of my coworkers that Windows device
driver
> development does make use of the copy/copyback.  It is not always used,
but
> there are situations where it is, and apparently they happen frequently
enough
> to be built into the tools.  Since D is meant to be a systems programming language, I suspect that similar issues will arise.
>
IMHO I don't think that this is a valid enough reason to implement
copy/writeback calls
especially as D supports array and structure assignment
copy/writeback has enough hidden pit falls that I feel it should be
performed manually if that is you true desire.
i.e.
create a copy, call function by params passed by ref, writeback
my guess is that in device driver dev you would be likely to want to do

synchronized(devicelock) { create a copy }
call function by params passed by ref,
synchronized(devicelock) {
    check writeback o.k.
    if so then writeback;
}

I would say support for CPU atomic read/write and read_modify_write is more important but like volatile the most robust solution is to have it as a storeage class and not an atomic statement

Mike. ::getting even further off topic::

I also prefer 'ref' to inout, also i would like to so 'in' dropped as nobody is ever going to use it, it is implicit and hence redundant. Its a waste of ascii.

chris


"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:angu34$4ba$1@digitaldaemon.com...
> Consider passing a value as "inout" parameter to a function.
> Then both the caller and the called functions continue to use the same
> value, by multithreading.
> Now when will the changes of the inout parameter be incorporated into the
> original variable?
> Immediately, or when the called function returns?
> The specification does not tell. (Walter: please put it in)
> The "inout" name suggests the later, but the first happens (i hope).
> Therefore the name "inout" is not really intuitive. I would rather suggest
> "ref", because what is happening is passing a parameter by reference.
>
> Sandor
>
>

Consistency is more important than a few keystrokes.  Contract qualifiers document the code; 'in' should be just as mandatory (or just as optional) as the other two.

Many languages have confused the issue of call-by-value and call-by-reference. This situation makes 'ref' a bad term.  A better term is 'shared.' The parameter is shared between caller and callee.

The term 'inout' is unhelpful.  It doesn't communicate what is actually happening.  Something goes in, and something comes out, but 'inout' fails to indicate that they are actually the *same* thing.

Beyond that the shared parameter might be unused and/or unchanged by the caller (as an output) or callee (as an input).  So 'inout' wrongly connotes usage of, and/or changes to, the parameter when they are in fact optional.  The term 'shared' has the right connotations.

Mark

In article <ani3ss$1djm$1@digitaldaemon.com>, chris jones says...
>
>I also prefer 'ref' to inout, also i would like to so 'in' dropped as nobody is ever going to use it, it is implicit and hence redundant. Its a waste of ascii.
>
>chris
>