http://groups.google.com/group/comp.programming.threads?hl=en
comp.programming.threads@googlegroups.com
Today's topics:
* Call for Papers: The 2009 International Conference on Computer Graphics and
Virtual Reality (CGVR'09), USA, July 13-16, 2009 - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/4515a1b06bd72998?hl=en
* Why are Boost thread mutexes so slow compared to Pthreads? - 7 messages, 5
authors
http://groups.google.com/group/comp.programming.threads/t/9c9fd9b9ccafc16a?hl=en
* AIR Jordan Fusions 13 NIKE Jordan Fusion 14 AIR Jordans 15Nike Jordan - 1
messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/6e687443d2cf526d?hl=en
==============================================================================
TOPIC: Call for Papers: The 2009 International Conference on Computer Graphics
and Virtual Reality (CGVR'09), USA, July 13-16, 2009
http://groups.google.com/group/comp.programming.threads/t/4515a1b06bd72998?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Jan 1 2009 12:04 am
From: "A. M. G. Solo"
Dear Colleagues:
I would appreciate if you would share the announcement below with
those who might be interested.
Best regards,
A. M. G. Solo
Publicity Chair, CGVR'09
------------------------
C A L L F O R P A P E R S
===============================
CALL FOR PAPERS
and
Call For Workshop/Session Proposals
The 2009 International Conference on Computer
Graphics and Virtual Reality
CGVR'09
Date and Location: July 13-16, 2009, Las Vegas, USA
You are invited to submit a paper (and/or a proposal to organize
a session/workshop). All accepted papers will be published in the
respective conference proceedings.
SCOPE: Topics of interest include, but are not limited to, the
following:
O Software tools for computer graphics
O Compression technologies
O Computational geometry
O Computer animation
O Shadows, translucency and visibility
O Fractal geometry and applications
O Rendering methods
O Illumination and reflection techniques
O Sound rendering technologies
O Surface modeling
O Multi-resolution modeling
O Web 3D and applications
O Color and texture
O Modeling techniques
O Visualization
O Machine architectures/engines for graphics and VR
O Modeling of natural scenes and phenomena
O Computer art and entertainment (including games)
O e-Learning applications and computer graphics
O Interactive digital media
O 3D reconstruction
O Curves and meshes
O Information visualization
O Visual computing and graphics
O Shape representation
O Image data structures for computer graphics
O Graphics algorithms and applications
O Case studies and emerging technologies
-----------
O Virtual and augmented reality
O Virtual environments
O Virtual humans and artificial life
O Real-time collision detection algorithms
O Immersive virtual reality
O Virtual reality, visualization, and education
O Haptic devices and techniques
O Interactive techniques
O Learning and assessment based on virtual reality approaches
O Virtual laboratories
O Virtual reality tools/languages (X3D, VRML, Java3D, OpenGL, ...)
O Real-time rendering for VR
O Emerging display technologies
O Virtual reality techniques for behavioral and cognitive
assessment
O Simulation and virtual reality
O Software tools for virtual reality
O Human-computer interfaces
O Multimodal display systems
O Integration of virtual reality and multimedia
O Virtual reality and emerging applications
Web links:
http://www.world-academy-of-science.org/worldcomp09/ws/conferences/cgvr09
http://www.world-academy-of-science.org/
ACADEMIC CO-SPONSORS:
Currently being prepared - it will include a number of active
research laboratories and centers that have helped to shape our
field. The Academic Co-Sponsors of the last offering of
CGVR included research labs at Harvard University, UCLA,
University of Minnesota, University of Illinois at Urbana-
Champaign, Georgia Institute of Technology, Emory University,
University of Texas at Austin, MIT, George Mason University,
University of Iowa, Russian Academy of Sciences, NEMO/European
Union, and others. Corporate Co-Sponsors included, Google,
Salford Systems, Synplicity, Supermicro, NIIT, and others.
General Co-Chair and Coordinator:
H. R. Arabnia, PhD
Professor, Computer Science
Editor-in-Chief, The Journal of Supercomputing (Springer)
Advisory Board, IEEE Technical Committee on TCSC
Vice President, Int'l Society of Intelligent Biological Medicine
The University of Georgia
Department of Computer Science
415 Boyd Building
Athens, Georgia 30602-7404, USA
Tel: (706) 542-3480
Fax: (706) 542-2966
E-mail: hra@cs.uga.edu
SUBMISSION OF PAPERS:
Prospective authors are invited to submit their draft papers by
uploading them to http://worldcomp.cviog.uga.edu/ .
Submissions must be received by Feb. 25, 2009 and they must be in
either MS doc or pdf formats (about 5 to 7 pages - single space,
font size of 10 to 12). All reasonable typesetting formats are
acceptable (later, the authors of accepted papers will be asked to
follow a particular typesetting format to prepare their papers for
publication.)
The length of the Camera-Ready papers (if accepted) will be limited
to 7 (IEEE style) pages. Papers must not have been previously
published or currently submitted for publication elsewhere. The
first page of the draft paper should include: title of the paper,
name, affiliation, postal address, and email address for each
author.
The first page should also identify the name of the Contact Author
and a maximum of 5 topical keywords that would best represent the
content of the paper. Finally, the name of the conference (CGVR)
must be mentioned on the first page.
Papers will be evaluated for originality, significance, clarity,
impact, and soundness. Each paper will be refereed by two experts
in the field who are independent of the conference program
committee.
The referees' evaluations will then be reviewed by two members of
the program committee who will recommend a decision to the co-
chairs.
The co-chairs will make the final decision. Lastly, the Camera-
Ready
papers will be reviewed by one member of the program committee.
PROPOSAL FOR ORGANIZING SESSIONS/WORKSHOPS:
Each session will have at least 6 paper presentations from
different authors (12 papers in the case of workshops). The
session chairs will be responsible for all aspects of their
sessions; including, soliciting papers, reviewing, selecting, ...
The names of session chairs will appear as Associate Editors in
the conference proceedings and on the cover of the books.
Proposals to organize sessions should include the following
information: name and address (+ email) of proposer, title of
session, a 100-word description of the topic of the session,
the name of the conference the session is submitted for
consideration (ie, CGVR'09), and a short description on how
the session will be advertised (in most cases, session proposers
solicit papers from colleagues and researchers whose work is
known to the session proposer). email your session proposal
to Prof. Arabnia (address is given above). We would like to
receive the proposals by January 16, 2009.
IMPORTANT DATES:
Jan. 16, 2009: Proposals for organizing/chairing sessions/
workshops
Feb. 25, 2009: Submission of papers (about 5 to 7 pages)
March 25, 2009: Notification of acceptance
April 25, 2009: Camera-Ready papers and Registration due
July 13-16, 2009: The 2009 International Conference on Computer
Graphics and Virtual Reality (CGVR'09)
MEMBERS OF PROGRAM AND ORGANIZING COMMITTEES:
The Program Committee includes members of chapters of World Academy
of Science (chapters: supercomputing; scientific computing; AI;
imaging science; databases; simulation; software engineering;
embedded systems; internet and web technologies; communications;
bioinformatics; computational biology; and computer security.)
The Program Committee for CGVR is currently being formed. Those
interested in joining the Program Committee should email Prof.
Arabnia
(hra@cs.uga.edu) the following information: Name, affiliation
and position, complete mailing address, email address, a short
biography together with research interests and the name of the
conference (CGVR) offering to help with.
Many who have already joined the committees of individual tracks
are renowned leaders, scholars, researchers, scientists and
practitioners of the highest ranks; many are directors of research
laboratories, fellows of various societies, heads/chairs of
departments, deans and provosts.
PURPOSE / HISTORY:
CGVR'09 is an annual research conference about computer graphics
and
virtual reality. It is being held jointly (same location and
dates)
with a number of other conferences (WORLDCOMP'09). WORLDCOMP is
the
largest annual gathering of researchers in computer science,
computer engineering and applied computing.
The motivation is to assemble a spectrum of affiliated research
topics
into a coordinated meeting held in a common place at a common time.
The main goal is to provide a forum for exchange of ideas in a
number
of research areas that interact. The model used facilitates
communication among researchers from all over the world in
different
fields of computer science, computer engineering and applied
computing. Both inward research (core areas of computer science
and
engineering) and outward research (multi-disciplinary, inter-
disciplinary,
and applications) will be covered during the event.
CGVR'09 and WORLDCOMP'09 will be composed of research
presentations,
keynote lectures, invited presentations, tutorials, panel
discussions,
and poster presentations. In recent past, keynote and/or tutorial
speakers included: Prof. David A. Patterson (U. of California,
Berkeley); Prof. Michael J. Flynn (Stanford U.); Prof. John H.
Holland
(U. of Michigan, Ann Arbor); Prof. Brian D. Athey (U. of Michigan,
Ann Arbor), Prof. H. J. Siegel (Colorado State U.); Prof. Barry
Vercoe
(MIT); Prof. Ruzena Bajcsy (U. of California, Berkeley);
Prof. Jun Liu (Harvard U.); Dr. Jim Gettys (OLPC + developer of X
Window); Dr. Chris Rowen (President and CEO, Tensilica, Inc.); and
many other distinguished speakers.
LOCATION OF CONFERENCES:
The conferences will be held in the Monte Carlo hotel, Las Vegas,
Nevada, USA (with any overflows at other near-by hotels). This is
a mega hotel with excellent conference facilities and over 3,000
rooms. It is minutes from the airport with 24-hour shuttle
service to and from the airport. This hotel has many recreational
attractions, including: waterfalls, spa, pools, sunning decks, Easy
River, wave pool, lighted tennis courts, health spa, nightly shows,
a number of restaurants, ... The negotiated room rate for
conference attendees is very reasonable. The hotel is within
walking distance from most other attractions (recreational
destinations, Golf courses, ...)
==============================================================================
TOPIC: Why are Boost thread mutexes so slow compared to Pthreads?
http://groups.google.com/group/comp.programming.threads/t/9c9fd9b9ccafc16a?hl=en
==============================================================================
== 1 of 7 ==
Date: Thurs, Jan 1 2009 11:32 am
From: Daniel James
In article
news:<67fcf98e-f6a5-4991-a177-fe2d54657685@q26g2000prq.googlegroups.com
>, David Schwartz wrote:
> On Dec 30, 2:00 am, Ulrich Eckhardt <dooms...@knuut.de> wrote:
>
> > > If it is illegal for Baz, Qutl and FooBar to throw an exception,
> > > then this is fine. But if that's the case, why bother with the
> > > ScopedLock?
>
> > The answer is expressiveness. It says this function is executed
> > with the lock held, so for the rest of the function you can
> > effectively forget about the mutex and the fact that the object
> > is used by several threads.
>
> But that's exactly what you can't do. You only want to hold the lock
> while the invariants are broken or the object must remain stable. You
> don't want to hold it for the entire scope ...
This is becoming a very chicken-and-egg argument!
You *do* want the lock to be held for the entire scope, because if you
are using a scoped lock you will have constructed a scope whose extent
is exactly the same as the extent of the lock. It works because you
make it work; you make it work because you value the expressiveness of
the idiom and the safety that it affords.
Cheers,
Daniel.
== 2 of 7 ==
Date: Thurs, Jan 1 2009 11:32 am
From: Daniel James
In article news:<Dln6l.28756$J84.23958@tornado.fastwebnet.it>,
Giancarlo Niccolai wrote:
> >> We just got shivers down our spines when we read them being
> >> "easier", "safer" and "better" (always). They're not. They're
> >> just another tool.
> >
> > I don't quite agree. Scoped locks *are* easier, safer, and better
> > than alternative programming techniques in those situations in
> > which scoped locks are an appropriate tool.
>
> Again, quite tautological. If one says "this tool is not always
> better" and the other replies "I don't agree. This tool is better,
> but not always, only in those situation when it is better"
Sorry, I think I must have missed the "(always)" in your post.
[snip]
> A point you seem to share, and still trying not to agree :-)
I agree that scoped locks aren't a magic wand that can be waved to
solve all scoping problems -- you do have to understand what they buy
you, what are the consequences of using them, and what they can't do.
I disagree with your suggestion that automating a process cannot make
that process easier and safer than doing it manually.
Your argument appears to amount to "if processes are automated there is
a danger that someone will invoke the wrong automated process". Which
is obviously true, but is no kind of argument against automation.
Cheers,
Daniel.
== 3 of 7 ==
Date: Thurs, Jan 1 2009 11:32 am
From: Daniel James
In article news:<ihd6l.31192$ly1.19012@newsfe19.iad>, Chris M.
Thomasson wrote:
> You can use a scoped unlock RAII helper object:
You can ... but you probably don't want to.
> static mutex g_mutex;
>
>
> void foo() {
> {
> scoped_lock lock(g_mutex);
>
> do_locked_stuff();
>
> {
> scoped_unlock unlock(g_mutex);
>
> do_unlocked_stuff();
>
> } // mutex.lock();
>
> do_more_locked_stuff();
>
> } // mutex.unlock();
> }
.. and if do_unlocked_stuff throws an exception the mutex will be
re-acquired in unlock's destructor just so that it can be released
again in lock's destructor ...
Much better just to use two separate scoped locks as David
Barrett-Lennard suggests in message
<8d853508-9fe5-4d7c-9bec-b786d1c27b9f@r15g2000prh.googlegroups.com>
Cheers,
Daniel.
== 4 of 7 ==
Date: Thurs, Jan 1 2009 12:23 pm
From: Giancarlo Niccolai
Daniel James ha scritto:
> In article news:<Dln6l.28756$J84.23958@tornado.fastwebnet.it>,
> Giancarlo Niccolai wrote:
>>>> We just got shivers down our spines when we read them being
>>>> "easier", "safer" and "better" (always). They're not. They're
>>>> just another tool.
> I disagree with your suggestion that automating a process cannot make
> that process easier and safer than doing it manually.
It CAN make it. It is not... automatic that it will make it.
>
> Your argument appears to amount to "if processes are automated there is
> a danger that someone will invoke the wrong automated process". Which
> is obviously true, but is no kind of argument against automation.
>
And in fact, I have never been against. I was against only in
advertising automation as always better. One must know its tools, or,
automation or not, they will shoot back.
GN.
== 5 of 7 ==
Date: Thurs, Jan 1 2009 2:44 pm
From: Ulrich Eckhardt
David Schwartz wrote:
> On Dec 30, 10:39 am, Ulrich Eckhardt <dooms...@knuut.de> wrote:
>
>> DS keeps coming up with the claim that you need a mutex to modify
>> invariants. I counter that invariants must be met regardless of multiple
>> threads,
>
> Perhaps you are using "invariants" in a different sense than I am. You
> don't need to restore invariants in a single thread. Why would a
> thread care if invariants are valid or invalid? Presumably, if they're
> invalid, the thread knows that they're invalid because it invalidated
> them. If it assumes they are valid, that's a bug that has nothing to
> do with multi-threading.
>
>> and that threads are synchronised using mutexes and otherwise the
>> invariants are not even accessible. A simple string modified in a
>> single-threaded program is the proof that you don't need a mutex to
>> modify any invariants.
>
> Let me define what I mean by invariants: An "invariant" is an
> assumption that a thread is permitted to assume holds any time it
> acquires a lock on an object.
Actually, yes, I'm using the term in a different sense than you do. To me,
an invariant of e.g. std::string is that its internal pointers are valid.
This is true once the constructor has finished until the destructor starts.
In between, any code operating on these pointers can assume that the
pointers are valid. Looking at wp, the article on invariants[2] is pretty
abstract and difficult to understand, the one on class invariants[3] is
more concrete.
Of course, there are times when these guarantees don't hold, e.g. when
reallocating, but that code is part of the internals, so externally, you
can never observe a state where the guarantees about the internal state
don't hold.
All the code of std::string is mostly[1] unaware of the fact that threads
exist. That means that when executed by more than one thread, there is no
builtin coordination between them, leading to errors. We add that missing
coordination using e.g mutexes. However, the invariants themselves are
useful and important even without threads.
Uli
[1] Making code suitable for multithreading e.g. requires that you don't use
static variables in order to make the code reentrant. Otherwise, there are
few limitations.
[2] http://en.wikipedia.org/wiki/Invariant_(computer_science)
[3] http://en.wikipedia.org/wiki/Class_invariant
== 6 of 7 ==
Date: Thurs, Jan 1 2009 7:02 pm
From: David Schwartz
On Jan 1, 11:32 am, Daniel James <wastebas...@nospam.aaisp.org> wrote:
> > But that's exactly what you can't do. You only want to hold the lock
> > while the invariants are broken or the object must remain stable. You
> > don't want to hold it for the entire scope ...
> This is becoming a very chicken-and-egg argument!
> You *do* want the lock to be held for the entire scope, because if you
> are using a scoped lock you will have constructed a scope whose extent
> is exactly the same as the extent of the lock.
Right, at the time of construction. The problem is three months later,
when you seed to add some new code in the middle of that scope, or at
the end of that scope, that cannot run with the lock.
> It works because you
> make it work; you make it work because you value the expressiveness of
> the idiom and the safety that it affords.
But it doesn't afford any safety. If you forget to restore invariants,
it releases the mutex automatically. How is that safe?
The only "safety" is that you "cannot forget to release the mutex".
However, every time you release the mutex, you must also restore
invariants, otherwise you are screwed. If you can forget to release
the mutex, you can forget to restore invariants.
If a scoped lock actually helps you avoid forgetting to unlock the
mutex, it's because your code is so complicated that it's not visually
obvious every place the mutex gets released. In this case, that means
it's also not visually obvious every place the invariants need to be
restored. This means your code is *unsafe*, since you cannot possibly
be sure it restores invariants every place it needs to.
DS
== 7 of 7 ==
Date: Thurs, Jan 1 2009 8:28 pm
From: "Chris M. Thomasson"
"Daniel James" <wastebasket@nospam.aaisp.org> wrote in message
news:VA.00001617.136993ca@nospam.aaisp.org...
> In article news:<ihd6l.31192$ly1.19012@newsfe19.iad>, Chris M.
> Thomasson wrote:
>> You can use a scoped unlock RAII helper object:
>
> You can ... but you probably don't want to.
>
>> static mutex g_mutex;
>>
>>
>> void foo() {
>> {
>> scoped_lock lock(g_mutex);
>>
>> do_locked_stuff();
>>
>> {
>> scoped_unlock unlock(g_mutex);
>>
>> do_unlocked_stuff();
>>
>> } // mutex.lock();
>>
>> do_more_locked_stuff();
>>
>> } // mutex.unlock();
>> }
>
> .. and if do_unlocked_stuff throws an exception the mutex will be
> re-acquired in unlock's destructor just so that it can be released
> again in lock's destructor ...
Sure. I don't really worry about performance issues during the "slow-paths"
resulting from exceptional situations... Humm... If there are enough
exceptions to create a synchronization bottleneck, well, your app is screwed
anyway; forget about it.
> Much better just to use two separate scoped locks as David
> Barrett-Lennard suggests in message
> <8d853508-9fe5-4d7c-9bec-b786d1c27b9f@r15g2000prh.googlegroups.com>
It works fine, but its not quite as "flexible"; IMVHO of course. How can you
use separate scoped locks in the following contrived pseudo-code:
static mutex g_mutex; // non-recursive!
// `foo_2' RULE 1: `Must' be called with `g_mutex' locked!
void foo_2();
void foo_1() {
scoped_lock lock(g_mutex);
do_locked_stuff();
foo_2();
do_more_locked_stuff();
}
// `foo_2' RULE 1: `Must' be called with `g_mutex' locked!
void foo_2() {
do_some_more_locked_stuff();
scoped_unlock unlock(g_mutex);
do_unlocked_stuff();
}
Lets say that `foo_2' needs the call to `do_some_more_locked_stuff' to be
atomic wrt a calling threads critical-section. This is why `foo_2' requires
the `g_mutex' to be locked by the calling thread. scoped_unlock can
sometimes be "useful".
==============================================================================
TOPIC: AIR Jordan Fusions 13 NIKE Jordan Fusion 14 AIR Jordans 15Nike Jordan
http://groups.google.com/group/comp.programming.threads/t/6e687443d2cf526d?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Jan 1 2009 11:41 pm
From: wholesaleg@126.com
shoes on
AIR Jordan 1 (paypal payment)(www.king-trade.cn )
AIR Jordan 2
AIR Jordan 3
AIR Jordan 4
AIR Jordan 5 (paypal payment)(www.king-trade.cn )
AIR Jordan 6 Rings
AIR Jordan 6
AIR Jordan 7
AIR Jordan 8
AIR Jordan 9 (paypal payment)(www.king-trade.cn )
AIR Jordan 10
AIR Jordan 11
AIR Jordan 12
AIR Jordan 13 (paypal payment)(www.king-trade.cn )
AIR Jordan 14
AIR Jordan 15
AIR Jordan 16
AIR Jordan 17
AIR Jordan 18
AIR Jordan 19
AIR Jordan 20 (paypal payment)(www.king-trade.cn )
AIR Jordan 21
AIR Jordan 22
AIR Jordan 23 (paypal payment)(www.king-trade.cn )
AIR Jordan 3.5
AIR AIR Jordan 4.5
AIR Jordan 7.5
AIR Jordan 9.5
AIR Jordan 12.5 (paypal payment)(www.king-trade.cn )
AIR Jordan 15.5
AIR Jordan 19.5
AIR Jordan 21.5
AIR Jordan Large Size Jordan
AIR Jordan Size 14 Jordan
AIR Jordan Size 15 shoes
AIR Jordan DMP
Nike air force one, air force 1, air force one low cut, air force one
high cut, air force one release date
Air force one, air foce one 25TH, af 1, af 1 25TH, Nike air force one
new releases, limited version
Air Force One (paypal payment)(www.king-trade.cn )
Air Force one 25TH
AF 1
AF 1 25TH (paypal payment)(www.king-trade.cn )
Dunk sb nike sb dunk nike dunk sb dunk sb high dunk sb low dunk sb
woman
Nike sb dunk Nike Dunk High SB nike dunk low premuim sb Nike SB Dunk
High Shimizu
Nike SB Dunk Pro Nike SB Dunk Dunk SB
Nike Dunk shoes
Dunk shoes for woman (paypal payment)(www.king-trade.cn )
Dunk low cut
Dunk high cut
AIR Jordans Fusion 1 Jordan 2 Fusion AIR Jordan 3 Nike Jordan Fusion
4
Jordan 5 shoes Nike Air Jordan 6 VI Force 1 Jordan Fusion AJF 6 AJF6
AJ6F Jordan 6 Rings Jordan 6 fusion (paypal payment)(www.king-
trade.cn )
AIR Jordan Fusions 13 NIKE Jordan Fusion 14 AIR Jordans 15Nike Jordan
16 Fusion Jordan 17 shoes Nike Air Jordans 18 XVIII Force 1 Jordan
Fusion AJF18 AJF18 AJ18F Jordan 18 fusions
(paypal payment)(www.king-trade.cn )
AIR Jordan Fusions 7 NIKE Jordan Fusion 8 AIR Jordans 9 Nikes Jordan
Fusion 10 Jordan 11 shoes Nike Air Jordan 12 XII Force 1 Jordan
Fusion AJF 12 AJF12 AJ12F Jordans 12 fusions
(paypal payment)(www.king-trade.cn )
NIKE AIR JORDAN FORCE FUSION SHOES AJF 5 V JORDANs 5 FUSION NIKE
JORDAN 5 FUSION SHOES AJF5 Nike Air Jordan XXIII 23 Force 1 Jordan
Fusion AJF 23 AJF23 AJ23F
(paypal payment)(www.king-trade.cn )
Nike Jordans Fusion 23 AIR Jordan 22 Jordan Fusions 21 AIR Jordans
Fusion 20 Jordan 19 shoes Air Jordan Force Fusion VIII (8), AJF 8
Nike (paypal payment)(www.king-trade.cn )
Air Jordan 17 XVII Force 1 Jordan Fusions AJF 17 AJF17 AJ17F Jordan
our website : www.king-trade.cn
==============================================================================
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