http://groups.google.com/group/comp.programming.threads?hl=en
comp.programming.threads@googlegroups.com
Today's topics:
* Indicating truncation to the calling process - 4 messages, 2 authors
http://groups.google.com/group/comp.programming.threads/t/6c6effa342f41ce6?hl=en
* Interrupts and mutual exclusion - 2 messages, 2 authors
http://groups.google.com/group/comp.programming.threads/t/d1b0fbd85967dd35?hl=en
==============================================================================
TOPIC: Indicating truncation to the calling process
http://groups.google.com/group/comp.programming.threads/t/6c6effa342f41ce6?hl=en
==============================================================================
== 1 of 4 ==
Date: Sun, Jan 31 2010 7:15 pm
From: karthikbalaguru
On Feb 1, 6:36 am, David Schwartz <dav...@webmaster.com> wrote:
> On Jan 31, 9:28 am, karthikbalaguru <karthikbalagur...@gmail.com>
> wrote:
>
>
>
>
>
> > Hi,
>
> > I understand that the msgrcv()
> > function would read a message from
> > the queue associated with the
> > message queue id and place it
> > in the buffer(userdefined).
>
> > Further, it has an argument of type
> > size_t that indicates the maximum
> > size(in bytes) of the message that can
> > be received or truncated incase of larger
> > message.
>
> > Incase of large messages, the
> > truncated part of the message shall
> > be lost . But is there a mechanism
> > to indicate the calling process about
> > truncation ? Or is there an alternate
> > API that has an feature of indicating
> > the calling thread of the truncation ?
> > Any ideas ?
>
> Just pass one extra byte of buffer space.
>
> Suppose you were going to pass, say, 1,024 bytes to 'msgrcv'. Instead,
> pass 1,025. If you get 1,025 bytes, then your 1,024 byte received
> would have truncated.
>
Hey David, Thx for your reply.
Okay, if we pass even a single
extra byte, it gets truncated.
The name 'MSG_NOERROR'
to truncate the message text if longer
than msgsz bytes is misleading :-(
Considering MSG_NOERROR
is specified, how will the calling
process know that the truncation
has happened as only few of the
messages are larger in my scenario ?
Thx in advans,
Karthik Balaguru
== 2 of 4 ==
Date: Mon, Feb 1 2010 3:40 pm
From: David Schwartz
On Jan 31, 7:15 pm, karthikbalaguru <karthikbalagur...@gmail.com>
wrote:
> Considering MSG_NOERROR
> is specified, how will the calling
> process know that the truncation
> has happened as only few of the
> messages are larger in my scenario ?
Say you were going to call with a 1,024 byte buffer. Simply call with
a 1,025 byte buffer instead. If you receive 1,025 bytes, then the
message was truncated.
DS
== 3 of 4 ==
Date: Mon, Feb 1 2010 5:43 pm
From: karthikbalaguru
On Feb 2, 4:40 am, David Schwartz <dav...@webmaster.com> wrote:
> On Jan 31, 7:15 pm, karthikbalaguru <karthikbalagur...@gmail.com>
> wrote:
>
> > Considering MSG_NOERROR
> > is specified, how will the calling
> > process know that the truncation
> > has happened as only few of the
> > messages are larger in my scenario ?
>
> Say you were going to call with a 1,024 byte buffer. Simply call with
> a 1,025 byte buffer instead. If you receive 1,025 bytes, then the
> message was truncated.
>
:-)
Karthik Balaguru
== 4 of 4 ==
Date: Mon, Feb 1 2010 6:08 pm
From: karthikbalaguru
On Feb 2, 6:43 am, karthikbalaguru <karthikbalagur...@gmail.com>
wrote:
> On Feb 2, 4:40 am, David Schwartz <dav...@webmaster.com> wrote:
>
> > On Jan 31, 7:15 pm, karthikbalaguru <karthikbalagur...@gmail.com>
> > wrote:
>
> > > Considering MSG_NOERROR
> > > is specified, how will the calling
> > > process know that the truncation
> > > has happened as only few of the
> > > messages are larger in my scenario ?
>
> > Say you were going to call with a 1,024 byte buffer. Simply call with
> > a 1,025 byte buffer instead. If you receive 1,025 bytes, then the
> > message was truncated.
>
> :-)
>
I think, this support for indicating
to the calling process about the
truncation of particular messages
should be added in msgrcv() .
Karthik Balaguru
==============================================================================
TOPIC: Interrupts and mutual exclusion
http://groups.google.com/group/comp.programming.threads/t/d1b0fbd85967dd35?hl=en
==============================================================================
== 1 of 2 ==
Date: Mon, Feb 1 2010 5:57 pm
From: karl bezzoto
Hi,
I have threequestions:
Q1) is it possible to disable/enable interrupts from a high level
language? I expect no but i saw on the web some c code showing how to
do this. Is this code used only in the absence of an operating system?
Q2) sempahores might be implemented by enabling/disabling interrupts.
does this mean naturally concurrent libraries run on kernel mode?
Hence calling underneath a kernel semaphore? what about Java
concurrency API
Q3) are the instructionS such as testandset, swap made atomic via
disabling/enabling interrupts?
Cheers and sorry for the non-technical wording of my questions.
== 2 of 2 ==
Date: Mon, Feb 1 2010 6:11 pm
From: David Schwartz
On Feb 1, 5:57 pm, karl bezzoto <karl.bezz...@googlemail.com> wrote:
> Q1) is it possible to disable/enable interrupts from a high level
> language? I expect no but i saw on the web some c code showing how to
> do this. Is this code used only in the absence of an operating system?
Q1: Yes it is. But it's not practical to do it unless you *are* the
operating system. Kernels can be written in C and can disable and
enable interrupts as needed.
> Q2) sempahores might be implemented by enabling/disabling interrupts.
> does this mean naturally concurrent libraries run on kernel mode?
> Hence calling underneath a kernel semaphore? what about Java
> concurrency API
Q2: If you are implementing semaphores entirely in user space, then
you won't implement them by enabling/disabling interrupts. On most
modern CPUs, it is possible to implement concurrent primitives like
semaphores and locks without needing any special privileges (such as
disabling interrupts). For implementations that have special
privileges anyway, such as kernel implementations, you can do so if
it's helpful.
The Java concurrency API will be implemented as part of the Java JVM
using whatever works best on the particular platform. On most
platforms, it uses the normal concurrency primitives for that
platform, though it can use "optimized" primitives on CPUs where
that's possible. This includes all modern CPUs, but just because it's
possible doesn't mean it's smart.
> Q3) are the instructionS such as testandset, swap made atomic via
> disabling/enabling interrupts?
On modern CPUs, even the non-atomic versions of those instructions
cannot be interrupted. So interrupts are not what's preventing them
from being atomic. Atomicity on a "test and set" or "swap" operation
requires preventing other CPUs from getting at the memory "in the
middle" of the operation, which is a problem that can't be solved by
disabling interrupts.
The simplest atomic operation would be an atomic increment. The need
for atomicity is that two increments on two different CPUs don't
result in readA, readB, increment A, incrementB, writeB thus resulting
in only one increment. Interrupts don't cause this problem, so
disabling interrupts can't solve it. (Plus, no modern CPU makes 'fast'
instructions like read/modify/write or test/set interruptible anyway.)
DS
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.programming.threads"
group.
To post to this group, visit http://groups.google.com/group/comp.programming.threads?hl=en
To unsubscribe from this group, send email to comp.programming.threads+unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.programming.threads/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment