Subject: Re: [sv-ec] Chapter 12 feedback
From: Neil Korpusik (Neil.Korpusik@eng.sun.com)
Date: Fri Feb 07 2003 - 15:16:38 PST
Comments on SV LRM 3.1 Draft 2
Chapter 12.
Section 12.1
- See editor's note. The semaphore and mailbox are being referred to as
primitives. They are actually built-in classes. The second paragraph needs
to be modified to not use the word "primitive".
Section 12.2
- Can the semaphore class be extended? Section 12.4.8 explicitly states
that a mailbox class can be used as a base class. Section 12.2 needs to
state the same thing.
- This section states the following for get() and put()
-- Obtain a key from the bucket: get()
-- Return a key from the bucket: put()
More precisely they should say: "Obtain one or more keys..."
"Return one or more keys..."
^^^^^^^^^^^
Section 12.2.3
- First sentence says "get() function", it should say "get() method".
- Second to last paragraph, first sentence, says "the task returns", it
should say "the method returns".
Section 12.3
- Last sentence, says "the task returns", it should say "the method returns".
Section 12.4
- The num() method is missing from the list at the end of this section.
Section 12.4.1
- What is returned by new()?
The prototype doesn't show the type of the returned value. The text
refers to this value as being "the mailbox identifier, or null". I think
it should say something like "the mailbox handle, or null".
- Last sentence of last paragraph says "If bound is non-zero, it represents
the size of the mailbox queue." I assume that if bound is less than
0 that a runtime error should be produced.
Section 12.4.3
- scalar is used in this section. Scalar is used all over the place in
this chapter. See sections:
12.4.3, 12.4.4, 12.4.5, 12.4.6, 12.4.7, 12.4.8
scalar needs to be changed to singular. The definitions of scalar that
are scattered around here should be deleted.
Section 12.4.5
- Next to last paragraph, first sentence, "Simple mailboxes are type-less..."
Why is the word "simple" in there? Shouldn't this word be deleted?
- The same sentence says "a single mailbox can send and receive any type of
data", it should say something like "a single mailbox can send and
receive different types of data", since there are restrictions on the
valid data types for a mailbox (e.g. singular).
Section 12.4.6
- Last paragraph mentions that "the function returns", this should be
replaced with "the method returns". There are 3 places to fix this in
this paragraph.
Section 12.4.8
- Same comment as 12.4.6 (3 places where "function" needs to be changed to
"method").
- Editor's note mentions section 19.4, it meant to say 12.4.
Section 12.5
- There is an inconsistency in the write-up as to whether there is a
runtime error or a compiler error when there is a type mismatch. See
first sentence, page 92 and the last paragraph of this section.
- The first sentence on page 92 refers to run-time type-checking as
"the default". This implies that there is a way to turn this off, is
there a way to do this? If not, drop the part that refers to this
as the default.
- Last paragraph mentions that the compiler checks the type of data
passed to put() and get(). What about peek()?
Section 12.6
- First paragraph, last sentence, mentions that events can be "dynamically
allocated and reclaimed". This seems to be discussing implementation
specifics. The user doesn't actually "allocate" an event does he?
- First paragraph, mentions twice about events that: "they can be
arguments to tasks and that they can be dynamically allocated and
reclaimed." This only needs to be stated once.
Section 12.6.1
- Last sentence, page 95, says that an edge triggers a latch. I think
you meant to say that an edge triggers a flip-flop.
Section 12.6.4
- Page 97, second paragraph below the editor's note, the second sentence
in this paragraph seems to contradict the first sentence.
"Both mechanisms can be used to wait for either a persistent or a non-
persistent event. The wait construct is only meaningful when the event
is persistent."
The second sentence seems to be incorrect.
- Next to last paragraph, first sentence uses the phrase "generic task".
This is an old Vera phrase. Shouldn't it just say task?
- I also have the same comment on the last paragraph that Stefen made this
morning about the order of execution of the statements within a fork/join
construct not being defined.
Section 12.8.1
- Should "null" always be in bold. There are a few places in this chapter
where it isn't.
Section 12.9
- scalar is used here. (also on page 25)
- Last paragraph, page 99, "Arguments to $wait_var() can be an array
subscript expressions..." Either drop the s at the end of expressions or
get rid of the "an" before array.
Neil
This archive was generated by hypermail 2b28 : Fri Feb 07 2003 - 15:17:15 PST