ssc-devel

ssc-devel@common-lisp.net

6 discussions

[ssc-devel] (1) question : ssc implementation; (2) code-share: some locking procedures onto SBCL
by Sean Champ 06 Aug '06

06 Aug '06

Hello, I had noticed, today, that SSC was mentioned in the 'recent projects' listing at common-lisp.net. I had wanted to find out what there was to the project, and so, I visited the project's home page. Upon reading the SSC specification -- that is a throughly impressive work, by the way, I think it must be helpful in explaining the materials of the project, to a developer who would be unfamiliar with the materials, and for clarifying the materials, as to a developer who may be already familiar with the materials. I consider that SSC should serve as a foundation for the support of what is addressed in the SSC specification, addressing it on a cross-platform basis, within a single codebase, such that may be applied across implementations of more systems. I consider that McCLIM may be patched to use SSC, but I would like to inquire: How do you prefer that the implementation of the SSC specification will be approached? Upon reading the SSC specification, it appears to me that the material of the SSC specification may be addressed, readily, directly onto the threading implementation in SBCL -- at mutexes and semaphorse, namely. In the more, I presume it may all be approached in extension of the SBCL threading implementation -- this, then, in the implementation onto SBCL. If the SSC project would be open for contributions in the implementation of the SSC specification, as within an SB-Threads environment, I would like to volunteer for the effort. I've attached to this email what represents the body of experience that I have had in regards to threading, in SBCL. As in summary about the attachment: 1) Given that I have not been in active development of any public systems, I consider that it may be of help, that I would present an item of code that I have written, in case you may accept my offer for to be a contributor onto SSC, onto SBCL. I would say that with the clause, in regards to commentary and documentation in the code: I had written that item of code at a time when there was no clear hope that it would be published. I do not much like the look of the text of it, now; it may appear somehow cruftified, of the commentary in the code. It is an item of available code -- and I have not touched it, in some while. (Given the character of some comments that I have observed about writing made of my person, I am certain that the text in the attached file would stand as if to insprire such commentary, again. At this point, I am not much concerned of it, though I observe that it is so.) 2) I'd consider it to be licensed as some public domain code, simply. 3) The code in the file constitutes an implementation of the following, onto SBCL: - Modal locking - i.e. read/write locking - Lock acquisition with timeout - A macro WITH-TIMER, made as an extension onto SBCL's SB-EXT:WITH-TIMEOUT macro. The extension suports that an actual TIMER object would be supplied to the macro. That, in turn, will support that a user-specified TIMEOUT-FUNCTION will be called on the timer, in case of a timeout. - The definition of a distinct condition type, LOCK-BLOCKED-ERROR, such that will be produced as a consequence of some defaulted values, then produced in a timed-out call to expansion of the WITH-TIMER macro - A trivial protocol for acquisition and release of locks; that protocol was implemented as to be driven on generic functions. - Some preliminary attempts at supporting the code, onto ACL hosts; I cannot expect that those attempts will be certain to work, and they are incomplete. I may recommend that that functions of the generic-function protocol would be regarded only as an example. When I had implemented it with a generic-function-driven protocol, I had wanted the range for flexibility, afforded with generic functions; I consider, now, that that was a premise taken in some naivete. Latterly, presently -- though the generic function qualities of it have supported that MODAL-LOCK objects would be used beside more directly MUTEX typed objects -- I woud not recommend that it would be applied as so. The set of operations that are used for standard method dispatching on generic functions, those operations should not need to be required, in the execution of a locking facility. Both of modal locks and absolute locks may be initialized via a one function. The differentiation of modality may be predicated on the value of a :MODE argument, typed (MEMBER :READ :WRITE NIL). There may be defined a single function operating for the release of a lock. That function may be defined as to operate by way of a simple two-typed dispatch -- handling a MODAL-LOCK (?) differently than a plainer LOCK, within the body of the function. If you would be interested in the contribution, I would be glad to clean up the attached code, and to address it onto SSC, as for an implementation of the SSC specification onto SBCL hosts. I look forward to being able to use SSC within implementations. I am impressed with the breadth and the quality of the SSC specification, and with your careful approach to the project, such that is apparent on consideration. I would be glad to have an opportunity to contribute. I recognize, it is your own perogative, as for how you will approach the implementation of SSC. Cordially, -- Sean Champ gimmal(a)gmail.com user 'schamp' at common-lisp.net

1 0

[ssc-devel] PASS-BARRIER/TIMEOUT is not useful.
by Marco Monteiro 05 Aug '06

05 Aug '06

I'm currently using pass-barrier/timeout heavily in the test suite. Apart from its use there, I can't see any use for it. Unless someone can think of an use for it, I think that it should be thrown out. Any thoughts? Cheers, Marco

2 2

[ssc-devel] Changes.
by Marco Monteiro 01 Aug '06

01 Aug '06

There are some changes in the specification. There is now a rationale (the start of, actually). This will need much work. Its current text is mainly some observation that were made in the CL Gardeners mailing list. I'll be working in this section of the document in the next weeks. Help would be greatly appreciated, of course. Names for synchronization primitives have been removed. In their place there is a new :reason key argument to all functions that can block the current thread. I gave the rationale for this in a previous email to this mailing list, and I'll put something in the specification when I find time to do it. What do you think? Is this better? (Note that names for synchronization primitives can be addressed with the new extension mechanism.) The major change is the new extension mechanism. Read the latest revision of the specification to know all about this. There is also an example of its use in the project page (http://common-lisp.net/project/ssc/). That is how I expect the mechanism to be used. Remember that all the changes to the specification are reversible. If you don't like something, please speak up. Comments, please. Cheers, Marco

1 0

[ssc-devel] Names of synchronization objects
by Marco Monteiro 29 Jul '06

29 Jul '06

All synchronization objects have names. Names can be used to help debugging: although there is still no way to get information on what a thread is up to (like the PROCESS-WHOSTATE in some implementations) this will probably be added in the future. The name mechanism is currently used by some implementations. I now think that this is not the right way to do it, for at least to reasons: * (minor reason) a thread can be acquiring a lock, or waiting on a condition variable, or passing a barrier, etc., in several different places. With the name, this cannot be discerned: a thread can be deadlocked in one of many different places. * (major reason) imagine you build some abstractions over SSC, like monitors, bounded-buffer, etc. These will be implemented with locks and condition variables, etc. If a thread is blocked because a bounded buffer is full, the 'whostate' of the process will be something like "Blocked on lock 'buffers's lock'", instead of something more reasonable like "Adding client to buffer". So, what if we drop names from all synchronization objects and instead add a &key argument to all function that can block? Basically, I'm proposing taking the approach of PROCESS-WAIT of some implementations, that accepts a whostate argument, and extend it to all functions that can block. We would then have code user like: (with-lock (mutex :info "Mutual exclusion to list of clients") (loop while (list-full-p list) do (condvar-wait cv :info "List of clients is full")) ...) and code built on a bounded-buffer implemented on SSC: (put process-bbuffer client :info "Add client for process buffer") Please comment. Cheers, Marco

1 0

[ssc-devel] WAIT-CONDVAR/TIMEOUT is not implementable.
by Marco Monteiro 28 Jul '06

28 Jul '06

The problem is that after the lock is released, we cannot respect the timeout because we must re-acquire the lock before returning. Three possible solutions: * drop the function * change the semantics so that the lock is not re-acquired before the function returns * specify that the re-acquiring of the lock has this problem and the function cannot be used reliably (although it is still useful in most cases.) POSIX threads has the third behaviour. The second is not the right thing(R), but I see uses for it. Comments, please. Cheers, Marco

1 0

[ssc-devel] Auto-nag: ssc please update your webpage
by root＠common-lisp.net 17 Jul '06

17 Jul '06

You are being nagged on because you have not created a sensible default webpage for your project. Please do so or you will be nagged again next week. All we ask is that you type in something about the project and perhaps some links to mailinglists etc. See common-lisp.net/project/clo/sp/index.html for a reasonable template. Some projects host their webpages somewhere else (eg. http://common-lisp.net/project/cl-ppcre) and if you're in the same situation you may put the following in your index.shtml: <HTML> <HEAD> <META HTTP-EQUIV="refresh" CONTENT="0;URL=YOURURLGOESHERE"> </HEAD> <BODY> </BODY> </HTML> Any questions? You can reach the author of this cronjob at clo-devel(a)common-lisp.net Thanks!

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

ssc-devel