http://groups.google.com/group/comp.programming.threads?hl=en
comp.programming.threads@googlegroups.com
Today's topics:
* Interrupts and mutual exclusion - 2 messages, 2 authors
http://groups.google.com/group/comp.programming.threads/t/d1b0fbd85967dd35?hl=en
* Rs 20,000 INR at stake in CodeWarrior - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/05b63fd13b282f21?hl=en
==============================================================================
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 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
== 2 of 2 ==
Date: Tues, Feb 2 2010 12:42 am
From: Marcel Müller
Hi,
karl bezzoto wrote:
> Q2) sempahores might be implemented by enabling/disabling interrupts.
no. Disabling IRQs is neither necessary nor sufficient. Think about
multi core CPUs.
> does this mean naturally concurrent libraries run on kernel mode?
No.
> Hence calling underneath a kernel semaphore?
Either this or using implicitly atomic instruction of the current
platform. If the synchronization should be used as IPC, in fact only the
kernel functions are an option.
> Q3) are the instructionS such as testandset, swap made atomic via
> disabling/enabling interrupts?
No. That won't help on SMP machines.
These atomic instructions are synchronized at the level of the cache and
memory controller.
Marcel
==============================================================================
TOPIC: Rs 20,000 INR at stake in CodeWarrior
http://groups.google.com/group/comp.programming.threads/t/05b63fd13b282f21?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Feb 2 2010 1:24 pm
From: "!!ankit!!"
CodeFest & IEEE present to you CodeWarrior - Either Win or Die Coding!
It is a completely Online event with two cumulative rounds, testing
all aspects of your computer knowledge, be it programming, logical
reasoning, debugging or algorithm design.
There are prizes worth 20,000 INR & Codechef T-Shirts for the winners.
Problem Statements for First Round will be released on Feb 5, 1800 Hrs
(IST). Here is the problem break-up:
* 2 Puzzles
* 2 Algorithm Designing Problems
* 2 C/C++ Debugging Problems
* 1 Algorithm Intensive Programming Challenge
Sample Problems are also available. Sumission Deadline : Feb 14, 2100
Hrs (IST).
It is a team event with maximum of 2 members. So form your team now
and get ready for some baffling puzzles, buggy codes & bewildering
algorithms.
For further questions email us at codefest@itbhu.ac.in or contact the
following:
Shishir Mittal: +91-9936-180-121 shishir.mittal.cse06@itbhu.ac.in
Other Events at Codefest
* GumboRumble : Problem statements for Adobe sponsored 2 months
long application development competition with prizes worth 50,000
INR, have been released. Registrations and Submissions closes on Feb
24 2100 Hrs (IST).
* MathMania : An event with Challenging Mathematical Problems as
in Project Euler, Scheduled on Mar 13.
* Manthan : An algorithm intensive programming competition on the
lines of ACM-ICPC, to be hosted on Codechef. Scheduled on Mar 14.
* Perplexed! : C obscure Programming Competition, to get in-depth
knowledge of C. Scheduled on Mar 21.
Be free and Happy Coding!
Team Codefest.
Website: http://itbhu.ac.in/codefest
Twitter: http://twitter.com/c0defest
Blog: http://codefest.wordpress.com
==============================================================================
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