Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Ian Collins Newsgroups: comp.programming.threads Subject: Re: A book for learning threads? Date: Wed, 07 Nov 2012 10:37:48 +1300 Lines: 44 Message-ID: References: <508dcd4d$0$7581$a8266bb1@newsreader.readnews.com> <5c142f28-f08c-4569-ab8e-e17257e6afd0@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net 5GJNX7b6nOWUae0Jiuyb+g71ovKtdxx6/K9MYrrviMMggJ7zF4kIJom9haGn1VFWUo Cancel-Lock: sha1:tAAowZ81inHO2SV2l2UOD1r+yl8= User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:12.0) Gecko/20120423 Thunderbird/12.0 In-Reply-To: Xref: csiph.com comp.programming.threads:1228 On 11/03/12 19:46, Robert Miles wrote: > 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. I still see this as a problem for the work unit rather than a threading one. Surly it would be easier for the work unit to know when would be a good time to dump its state rather than rely on an application wide mechanism? If the computations use multiple threads, each thread could save its own state. -- Ian Collins