Mutex after STB copy

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Mutex after STB copy

Bill Schwab-2
Hi Blair,

For a while now, I have been binary filing and later re-loading objects that
contain a mutex.  Some time ago, I had encountered a problem and started
replacing the mutex after reload, but I'm pretty sure I never understood why
it was necessary.  This came up again yesterday, and it looked somewhat
ominous at first.  However, I think all that was happening was that I was
copying the owning object (and therefore the mutex) inside a critical
section where the semaphore's signal is consumed; it then in-files the same
way, and the assumed condition of having an excess signal at creation does
not hold.  Here's an example:

| mutex mutexCopy |
mutex := Mutex new.
mutex critical:[
  mutexCopy := Object fromBinaryStoreBytes:mutex binaryStoreBytes.
].
mutexCopy critical:[
  nil halt.
].

Seem reasonable?  If so, what do you think about my fix of replacing the
mutex after in-filing?  Is there a better way?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Mutex after STB copy

Blair McGlashan
"Bill Schwab" <[hidden email]> wrote in message
news:akl8is$1jhtv3$[hidden email]...
>
> For a while now, I have been binary filing and later re-loading objects
that
> contain a mutex.  Some time ago, I had encountered a problem and started
> replacing the mutex after reload, ...[snip]... I think all that was
happening was that I was
> copying the owning object (and therefore the mutex) inside a critical
> section where the semaphore's signal is consumed; it then in-files the
same
> way, and the assumed condition of having an excess signal at creation does
> not hold....

Yes that sounds right. A general solution probably requires some kind of
work at the STB level (e.g. a proxy class for Mutex).

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

RE: Mutex after STB copy

Smalltalkiano-4
In reply to this post by Bill Schwab-2
Hi Bill,

    we found that situation binarying aMutex, and now we simply do not do
that.

    It isn't a beauty but we by that time we store
anObjectComposedWithAMutex with a nil instead of the mutex. Finally we
managed to don't need to store the mutex at all.

    best regards,

Seb






Bill Schwab <[hidden email]> escribió en el mensaje de noticias
akl8is$1jhtv3$[hidden email]...
> Hi Blair,
>
> For a while now, I have been binary filing and later re-loading objects
that
> contain a mutex.  Some time ago, I had encountered a problem and started
> replacing the mutex after reload, but I'm pretty sure I never understood
why
> it was necessary.  This came up again yesterday, and it looked somewhat
> ominous at first.  However, I think all that was happening was that I was
> copying the owning object (and therefore the mutex) inside a critical
> section where the semaphore's signal is consumed; it then in-files the
same

> way, and the assumed condition of having an excess signal at creation does
> not hold.  Here's an example:
>
> | mutex mutexCopy |
> mutex := Mutex new.
> mutex critical:[
>   mutexCopy := Object fromBinaryStoreBytes:mutex binaryStoreBytes.
> ].
> mutexCopy critical:[
>   nil halt.
> ].
>
> Seem reasonable?  If so, what do you think about my fix of replacing the
> mutex after in-filing?  Is there a better way?
>
> Have a good one,
>
> Bill
>
> --
> Wilhelm K. Schwab, Ph.D.
> [hidden email]
>
>