Received: by 10.224.180.141 with SMTP id bu13mr2204790qab.2.1351925166904; Fri, 02 Nov 2012 23:46:06 -0700 (PDT) Received: by 10.236.126.227 with SMTP id b63mr317320yhi.0.1351925166865; Fri, 02 Nov 2012 23:46:06 -0700 (PDT) Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!c7no4053841qap.0!news-out.google.com!gf5ni18188417qab.0!nntp.google.com!c7no4201219qap.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.programming.threads Date: Fri, 2 Nov 2012 23:46:06 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=72.148.29.235; posting-account=NqgFNQoAAADaQQLNa_lxY-2vNDSEyZjN NNTP-Posting-Host: 72.148.29.235 References: <508dcd4d$0$7581$a8266bb1@newsreader.readnews.com> <5c142f28-f08c-4569-ab8e-e17257e6afd0@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: A book for learning threads? From: Robert Miles Injection-Date: Sat, 03 Nov 2012 06:46:06 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Received-Bytes: 3379 Xref: csiph.com comp.programming.threads:1219 On Friday, November 2, 2012 8:52:55 PM UTC-5, Ian Collins wrote: > On 10/30/12 19:49, Robert Miles wrote: > > > On Monday, October 29, 2012 11:35:14 AM UTC-5, Lucas Levrel wrote: > > >> If it already uses Pthreads and compiles on these platforms, where's the > >> worry? Just stick with the Pthread implementation of the threads concept. > > Please trim your lines and tidy up the mess google makes of your replies! Trying. > > There's no desire to have it run only on platforms that can run for a > > month or more without any interruptions. Adding checkpoints so that it > > can resume with less computer time lost due to any interruptions REQUIRES > > understanding threads so that I can suspend all threads except the main > > thread when writing checkpoints or restoring from them. I don't yet know > > if it also requires telling all the other threads to place information > > specific to those threads where the main thread can find it and include it > > in the checkpoint.. > > Applications like BOINC typically dish out units of work to client > machines and these in turn pass them on to worker threads. In this > case, it makes sense for the unit of work to be scaled to be a) useful > and b) small enough so not too much is wasted if the machine dies during > processing. > > Saving state part way through a work unit probably isn't worth while. > > Make your "checkpoints" the completion of a work unit. There's no good division of the process to allow the many of the workunits to be less than a month long, and sometimes longer. If there was, checkpoints would already be available. There's also a much smaller type of workunits for the much shorter RNAs; these already have checkpoints at the end of each section of RNA. However, this doesn't work for the larger RNAs, such as most of those found in humans and other mammals. The nature of the problem just doesn't allow doing much with arbitrarily chopped pieces of the RNA.